more updated content to display on the new site

412/hardware-strats.md

@@ -1,69 +1,60 @@
-# Hardware deployment Strategies
+Data storage
+============
 
+Spinning Disks
+--------------
 
-## Virtual Desktop Interface
+Cheaper for more storage
 
-aka 0-Clients: network hosted OS is what each client would use.
+RAID - Redundant Array of Independent Disk
+------------------------------------------
 
-In some cases that network is a pool of servers which are tapped into.
-Clients can vary in specs like explained below(context: university):
+Raid 0: basically cramming multiple drives and treating them as one.
+Data is striped across the drives but if one fails then you literally
+lose a chunk of data.
 
-> Pool for a Library
+Raid 1: data is mirrored across the drives so it's completely redundant
+so if one fails the other is still alive. It's not a backup however
+since file updates will affect all the drives.
 
-Clients retain low hardware specs since most are just using office applications and not much else.
+Raid 5: parity. Combining multiple drives allows us to establish the
+parity of the data on other drives to recover that data if it goes
+missing.(min 3 drives)
 
-> Pool for an Engineering department
+Raid 6: same in principle as raid 5 but this time we have an extra drive
+for just parity.
 
-Clients connect to another pool where both clients and pool have better hardware specs/resources.
+Raid 10: 0 and 1 combined to have a set of drives in raid 0 and putting
+those together in raid 1 with another equally sized set of drives.
 
-The downside is that there is _1 point of failure_.
-The pool goes down and so does everyone else, meaning downtime is going to cost way more than a single machine going down.
+Network Attached Storage - NAS
+------------------------------
 
+Basically space stored on the local network.
 
+Storage Attached Network - SAN
+------------------------------
 
-# Server Hardware Strategies
+Applicable when we virtualise whole os's for users, we use a storage
+device attached to the network to use different operating systems
 
-> All eggs in one basket
+Managing Storage
+================
 
-Imagine just one server doing everything
+Outsourcing the storage for users to services like Onedrive because it
+becomes their problem and not ours.
 
-* Important to maintain redundancy in this case
-* Upgrading is a pain sometimes
+Storage as a Service
+====================
 
+Ensure that the OS gets its own space/partition on a drive and give the
+user their own partition to ruin. That way the OS(windows) will just
+fill its partition into another dimension.
 
-> Buy in bulk, allocate fractions
+Backup
+======
 
-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.
+Other people's data is in your hands so make sure that you backup data
+in some way. Some external services can be nice if you find that you
+constantly need to get to your backups. Tape records are good for
+archival purposes; keep in mind that they are slow as hell.