From a03d17a4293c337894fe6c70bc9b52709240ce96 Mon Sep 17 00:00:00 2001 From: shockrahwow Date: Mon, 16 Sep 2019 19:39:36 -0700 Subject: [PATCH] more hardware notes --- 412/hardware-strats.md | 45 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/412/hardware-strats.md b/412/hardware-strats.md index 5aa2d87..5945efa 100644 --- a/412/hardware-strats.md +++ b/412/hardware-strats.md @@ -21,4 +21,49 @@ The pool goes down and so does everyone else, meaning downtime is going to cost +# Server Hardware Strategies +> All eggs in one basket + +Imagine just one server doing everything + +* Important to maintain redundancy in this case +* Upgrading is a pain sometimes + + +> Buy in bulk, allocate fractions + +Basically have a server that serves up varies virtual machines. +# Live migration + +Allows us to move live running virtual machines onto new servers if that server is running out of resources. + +# Containers + +_docker_: Virtualize the service, not the whole operating system + +# Server Hardware Features + +> Things that server's benefit from + +* fast i/o +* low latency cpu's(xeons > i series) +* expansion slots +* lots of network ports available +* EC memory +* Remote control + +Patch/Version control on server's + +Scheduling is usually slow/more lax so that server's don't just randomly break all the time. + +# Misc + +Uptime: more uptime is _going_ to be more expensive. Depending on what you're doing figure out how much downtime you can afford. + + +# Specs + +Like before _ecc memory_ is basically required for servers, good number of network interfaces, and solid disks management. + +Remember that the main parameters for choosing hardware is going to be budget, and necessity; basically what can you get away with on the budget at hand.