3 ms·

The "livestock vs pets" comparison seems off. It's assumed with the livestock you can lose one server and don't care much – though with real animal livestock if

The "livestock vs pets" comparison seems off. It's assumed with the livestock you can lose one server and don't care much – though with real animal livestock if your cow gets ill you don't kill it and order more healthy cows. And the comparison also assumes you cannot kill the "pet" server. I have many pet servers with carefully chosen names, but I still can painlessly kill them and redeploy with the same name because I have Ansible or SaltStack code to do so

bayindirh 4y ago
The term originates from CERN mostly, which does HPC stuff in its data center. We are also an HPC center, and it's very fitting. The cattle servers are generally HPC worker nodes. Your users don't notice when a cattle server goes offline. Scheduler reschedules the lost jobs with high priority, so they restart/resume soon. But, pet servers on the other hand are generally coordinators of the cattle, like your shepherd dogs, keeping them in order, or giving them orders. Losing them is really creates bigger problems, and you need to tend them quick, even if you have failovers, etc. (which we certainly have). You can re-deploy a pet server pretty quickly, but they generally have an uptime of ~2 years, and reinstallation periods of 5-6 years, if ever. We upgrade them as much as we can.
d110af5ccf 4y ago
> I still can painlessly kill them and redeploy with the same name because I have Ansible or SaltStack code to do so those don't sound like pets to me ...
tetha 4y ago
> The "livestock vs pets" comparison seems off. It's assumed with the livestock you can lose one server and don't care much – though with real animal livestock if your cow gets ill you don't kill it and order more healthy cows. Honestly, in most environments, it's like that. You don't delete a postgres server because a component crashed weirdly. You take a look at that component and see if there is a deeper reason for that crash and if there is a more important root cause to fix. That would prevent issues on a lot of other systems. However, it's important to have the option to delete and rebuild the server. For example, we had a root drive corruption cause by some storage issues at the hoster on the server and binaries would crash in weird ways. At that point, I probably could fix the server by syncing binaries from other systems and such, but it's much easier to just drop it and rebuild it. And that's very much how larger groups of animals are handled. > And the comparison also assumes you cannot kill the "pet" server. I have many pet servers with carefully chosen names, but I still can painlessly kill them and redeploy with the same name because I have Ansible or SaltStack code to do so Those don't sound like pets. For historic reasons, I have systems on which external agencies and consultancies have done things outside of the configuration management I don't know. And given the house of cards piled up on some of the systems, I don't think anyone knows how to redo that system. That's a pet. Once I delete that system, it never comes back the same way.

bayindirh 4y ago

The term originates from CERN mostly, which does HPC stuff in its data center. We are also an HPC center, and it's very fitting. The cattle servers are generally HPC worker nodes. Your users don't notice when a cattle server goes offline. Scheduler reschedules the lost jobs with high priority, so they restart/resume soon. But, pet servers on the other hand are generally coordinators of the cattle, like your shepherd dogs, keeping them in order, or giving them orders. Losing them is really creates bigger problems, and you need to tend them quick, even if you have failovers, etc. (which we certainly have). You can re-deploy a pet server pretty quickly, but they generally have an uptime of ~2 years, and reinstallation periods of 5-6 years, if ever. We upgrade them as much as we can.

d110af5ccf 4y ago

> I still can painlessly kill them and redeploy with the same name because I have Ansible or SaltStack code to do so those don't sound like pets to me ...

tetha 4y ago

> The "livestock vs pets" comparison seems off. It's assumed with the livestock you can lose one server and don't care much – though with real animal livestock if your cow gets ill you don't kill it and order more healthy cows. Honestly, in most environments, it's like that. You don't delete a postgres server because a component crashed weirdly. You take a look at that component and see if there is a deeper reason for that crash and if there is a more important root cause to fix. That would prevent issues on a lot of other systems. However, it's important to have the option to delete and rebuild the server. For example, we had a root drive corruption cause by some storage issues at the hoster on the server and binaries would crash in weird ways. At that point, I probably could fix the server by syncing binaries from other systems and such, but it's much easier to just drop it and rebuild it. And that's very much how larger groups of animals are handled. > And the comparison also assumes you cannot kill the "pet" server. I have many pet servers with carefully chosen names, but I still can painlessly kill them and redeploy with the same name because I have Ansible or SaltStack code to do so Those don't sound like pets. For historic reasons, I have systems on which external agencies and consultancies have done things outside of the configuration management I don't know. And given the house of cards piled up on some of the systems, I don't think anyone knows how to redo that system. That's a pet. Once I delete that system, it never comes back the same way.