March 9, 2017 at 7:22 am
Comments posted to this topic are about the item Database Cattle
March 9, 2017 at 9:34 am
Convince my CEO and CFO that we should spend the money on the hardware and licenses to treat servers like cattle... :Whistling:
March 9, 2017 at 10:25 am
I have a new analogy. Computers as living spaces. A tent vs a condo vs. a house vs. a private island. You will never invest as much in your tent as you would in your permanent residence or your private island! tents are purpose built, easily replicated, and are marginally easy to replace. I wouldn't store my personal valuables in a tent, nor try to take my home camping. (just another comment from one of the trees!)
March 9, 2017 at 11:45 am
One of the ways that I think this can be achieved most easily is through the use of VMs & keeping not just snapshots, but full images of VMs, as well as creating base images with the Sql serverset up, but no data. That way, not only do you have the ability to quickly spin up a VM to test backup restores, you also have a standard template for setting up a new database server. I think that virtualizing everything is the best path to not only make sure you have redundancies baked into your system from the start, but also enables a more effective devops pipeline.
For example, a developer can spin up a VM on their local machine or ona development environment to build a new server, design a database / application, (in addition, having an under-powered test environment will make performance issues that could come with scale a bit more obvoius from the outset) , and when they are ready to put something into testing or production move it to a new environment.
Through virtualization, not only can you set up any one of the numerous HA technologies available to keep a VM up and running, but it makes it easy to clone existing environments for testing, reporting/auditing, etc. To me, a server is just where a VM happens to reside. I try to avoid doing anything on bare metal.
March 9, 2017 at 11:55 am
As an admin who grew up near livestock i disagree the Cattle analogy. You want a parallel to farming I'd like at modern hog industry. The hog is the data and not the building they are housed in.
Hardware Is a tangible asset, as are the farrowing, growing and finishing buildings for the hog farmer. As we struggle with our DR planning is very much like a farmer who would be concerned about a tornado wiping our a building in which the hogs are contained. But the parallel about ends there. a farmer can if assets and cash flow allows to set up multiple sites for his operation too but it comes at an economic cost. Infrastructure additional labor etc. it doesn't eliminate loss in the event of a catastrophe, it only can minimize the loss a bit.
In a DR condition, the farmer not only losses the building he also losses the livestock . A farmer cant avoid loss of stock in disaster, we can avoid loss of data. Our costs are infrastructure and labor.
March 9, 2017 at 11:57 am
That's all well and good, but you best remember to treat your database administrators like pampered pets rather than commodity cattle, or else we'll wander off and get our fur stroked somewhere else.
:satisfied:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 9, 2017 at 12:22 pm
chrisn-585491 - Thursday, March 9, 2017 9:34 AMConvince my CEO and CFO that we should spend the money on the hardware and licenses to treat servers like cattle... :Whistling:
Well, when you have an issue, or need to rebuild one because of hardware failures, he/she should hope these are cattle. Things easily recreated, not crafted because of a particular person's skill.
March 9, 2017 at 12:24 pm
Steven.Grzybowski - Thursday, March 9, 2017 11:45 AMOne of the ways that I think this can be achieved most easily is through the use of VMs & keeping not just snapshots, but full images of VMs, as well as creating base images with the Sql serverset up, but no data. That way, not only do you have the ability to quickly spin up a VM to test backup restores, you also have a standard template for setting up a new database server. I think that virtualizing everything is the best path to not only make sure you have redundancies baked into your system from the start, but also enables a more effective devops pipeline.For example, a developer can spin up a VM on their local machine or ona development environment to build a new server, design a database / application, (in addition, having an under-powered test environment will make performance issues that could come with scale a bit more obvoius from the outset) , and when they are ready to put something into testing or production move it to a new environment.
Through virtualization, not only can you set up any one of the numerous HA technologies available to keep a VM up and running, but it makes it easy to clone existing environments for testing, reporting/auditing, etc. To me, a server is just where a VM happens to reside. I try to avoid doing anything on bare metal.
True, though what I find is that people always manage to forget to update some VM baseline that is needed. You still need configuration and settings data kept separately, whether you use a physical or virtual system. The data is what matters, including metadata.
March 9, 2017 at 12:28 pm
rmueller 80450 - Thursday, March 9, 2017 11:55 AMAs an admin who grew up near livestock i disagree the Cattle analogy. You want a parallel to farming I'd like at modern hog industry. The hog is the data and not the building they are housed in. Hardware Is a tangible asset, as are the farrowing, growing and finishing buildings for the hog farmer. As we struggle with our DR planning is very much like a farmer who would be concerned about a tornado wiping our a building in which the hogs are contained. But the parallel about ends there. a farmer can if assets and cash flow allows to set up multiple sites for his operation too but it comes at an economic cost. Infrastructure additional labor etc. it doesn't eliminate loss in the event of a catastrophe, it only can minimize the loss a bit. In a DR condition, the farmer not only losses the building he also losses the livestock . A farmer cant avoid loss of stock in disaster, we can avoid loss of data. Our costs are infrastructure and labor.
I think you're missing the analogy. Cattle meaning every one is replaceable. This has nothing to do with the other infrastructure. The cattle are the servers, and recreating one is a matter of having the data. Whether in that structure or another.
If I lose a building, I should always be able to hit Amazon, Microsoft, Google, or someone else with my config, and rebuild my servers (cattle) immediately. I shouldn't have to treat them special and have a particular person ready to recreate one, which is a one of a kind (a pet).
March 9, 2017 at 12:32 pm
Steve Jones - SSC Editor - Thursday, March 9, 2017 12:24 PMSteven.Grzybowski - Thursday, March 9, 2017 11:45 AMOne of the ways that I think this can be achieved most easily is through the use of VMs & keeping not just snapshots, but full images of VMs, as well as creating base images with the Sql serverset up, but no data. That way, not only do you have the ability to quickly spin up a VM to test backup restores, you also have a standard template for setting up a new database server. I think that virtualizing everything is the best path to not only make sure you have redundancies baked into your system from the start, but also enables a more effective devops pipeline.For example, a developer can spin up a VM on their local machine or ona development environment to build a new server, design a database / application, (in addition, having an under-powered test environment will make performance issues that could come with scale a bit more obvoius from the outset) , and when they are ready to put something into testing or production move it to a new environment.
Through virtualization, not only can you set up any one of the numerous HA technologies available to keep a VM up and running, but it makes it easy to clone existing environments for testing, reporting/auditing, etc. To me, a server is just where a VM happens to reside. I try to avoid doing anything on bare metal.
True, though what I find is that people always manage to forget to update some VM baseline that is needed. You still need configuration and settings data kept separately, whether you use a physical or virtual system. The data is what matters, including metadata.
I think as far as keeping a base image up to date, either monthly or quarterly reviews of a base image could be done to ensure that updates are applied. This would include ensuring that no new software had to be added to the baseline image, as well as updating the software & configurations for it. Perhaps keep a running copy of the baseline image that is only used for keeping up with updates, whether to windows, SQL server or other software used in the baseline image.
March 9, 2017 at 3:16 pm
The ability to programmatically configure a server using PoSh DSC, Chef, Puppet, or some other tool sounds great, though perhaps a little beyond where I want my career to go (being more on the BI side of things).
However, I will say I actively work to minimize (and document) customizations to an out-of-the-box setup. For example, eliminating SSIS packages stored on the file system. Eliminating linked servers & queries that run across linked servers as much as possible (vs. running the query on the other server directly). Moving away from spaghetti setups that work fine, but become really brittle if the server changes. Regular server migrations help identify brittleness too.
It's the same with SSMS or even Office (for example). I have a few small adjustments I make, but I don't spend a ton of time configuring it because I don't want to be thrown for a loop if I have to work in a standard configuration. Being highly tuned to a highly customized setup can backfire.
Which reminds me of the first time I visited a school in France. The French student we were visiting started typing, painfully slowly. He clearly had no idea where the letters were, let alone type at speed. "Let me do it", demanded my British friend. My friend pushed the French student out of the way, put all 8 fingers on the keyboard, and started typing with confidence. Nothing but nonsense appeared on screen. (Because French keyboards put keys in very different places to British keyboards.)
Leonard
Madison, WI
March 9, 2017 at 3:18 pm
Steve Jones - SSC Editor - Thursday, March 9, 2017 12:28 PMrmueller 80450 - Thursday, March 9, 2017 11:55 AMAs an admin who grew up near livestock i disagree the Cattle analogy. You want a parallel to farming I'd like at modern hog industry. The hog is the data and not the building they are housed in. Hardware Is a tangible asset, as are the farrowing, growing and finishing buildings for the hog farmer. As we struggle with our DR planning is very much like a farmer who would be concerned about a tornado wiping our a building in which the hogs are contained. But the parallel about ends there. a farmer can if assets and cash flow allows to set up multiple sites for his operation too but it comes at an economic cost. Infrastructure additional labor etc. it doesn't eliminate loss in the event of a catastrophe, it only can minimize the loss a bit. In a DR condition, the farmer not only losses the building he also losses the livestock . A farmer cant avoid loss of stock in disaster, we can avoid loss of data. Our costs are infrastructure and labor.I think you're missing the analogy. Cattle meaning every one is replaceable. This has nothing to do with the other infrastructure. The cattle are the servers, and recreating one is a matter of having the data. Whether in that structure or another.
If I lose a building, I should always be able to hit Amazon, Microsoft, Google, or someone else with my config, and rebuild my servers (cattle) immediately. I shouldn't have to treat them special and have a particular person ready to recreate one, which is a one of a kind (a pet).
I understand your analogy. just different way i look at it. I know some servers are pets for people. like a 4H calf.
March 9, 2017 at 3:46 pm
Steve Jones - SSC Editor - Thursday, March 9, 2017 12:28 PMrmueller 80450 - Thursday, March 9, 2017 11:55 AMAs an admin who grew up near livestock i disagree the Cattle analogy. You want a parallel to farming I'd like at modern hog industry. The hog is the data and not the building they are housed in. Hardware Is a tangible asset, as are the farrowing, growing and finishing buildings for the hog farmer. As we struggle with our DR planning is very much like a farmer who would be concerned about a tornado wiping our a building in which the hogs are contained. But the parallel about ends there. a farmer can if assets and cash flow allows to set up multiple sites for his operation too but it comes at an economic cost. Infrastructure additional labor etc. it doesn't eliminate loss in the event of a catastrophe, it only can minimize the loss a bit. In a DR condition, the farmer not only losses the building he also losses the livestock . A farmer cant avoid loss of stock in disaster, we can avoid loss of data. Our costs are infrastructure and labor.I think you're missing the analogy. Cattle meaning every one is replaceable. This has nothing to do with the other infrastructure. The cattle are the servers, and recreating one is a matter of having the data. Whether in that structure or another.
If I lose a building, I should always be able to hit Amazon, Microsoft, Google, or someone else with my config, and rebuild my servers (cattle) immediately. I shouldn't have to treat them special and have a particular person ready to recreate one, which is a one of a kind (a pet).
But that's why it's a bad analogy, while beef might be a replaceable commodity to the consumer cattle certainly are not to a farmer. Nor should servers be to an administrator, there is a certain amount of coddling and special care that every server requires(even cloud services), that doesn't mean you need to be sentimental about it in terms of replacing or upgrades but even with cloud services swapping out a server is not going to be zero cost.
March 9, 2017 at 4:43 pm
It's not about zero cost. It's not about being unable to change or customize a server. It's about being able to. It's about having things scripted so that you can recreate the server.
Far, far too many people have servers that they've customized and altered without any documentation. That's treating them like pets, because if something goes wrong, then you can't easily fix things or recreate the environment. IT is littered with stories of downtime and issues trying to rebuild a server that failed. People try desparately to keep systems alive or avoid rebuilding precisely because they don't know what to do.
Cattle are eminently replaceable to cattle farmers. They live with the idea that some will die, hence the need to have multiple cattle in a herd. We're not talking about wiping out every system. That's not the analogy, and if a cattle farmer loses all cattle or a company loses all servers, they're probably done. This is about any particular item not really mattering. If I lose one, I replace it.
March 10, 2017 at 12:23 am
It has long been possible to do a complete unattended install of SQL Server with detailed configuration and chain that into a complete virtual server build. We know this because Amazon do it, that is what an RDS instance is.
Is it easy to put together that facility yourself? No, of course not, it is quite a steep learning curve and you will attempt it many times before you get it right.
Once you can do it on a VM you can take what you have learned and apply it to your physical world. You will have to make tweaks to the process and in the non-virtual world there are dependencies not under your control.
It's one of those things that is daunting to people who haven't done it before and recognise that spinning up a stateless system such as a web server is a very different proposition to a stateful machine.
The bit of the analogy I don't like is the towny assumption about cattle rearing. Look what the local vet drives. That wasn't funded by pampered pooches and cosseted cats.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply