API tools faq
paste
Advertisement
Guest User

Untitled

a guest
Feb 7th, 2018
750
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 46.59 KB | None | 0 0
raw download clone embed print report
  1. Rules for Server Virtualization
  2. Mini magick20170719 13268 14vry2n medium
  3.  
  4. by Danielgingerich on Feb 7, 2018 at 11:50 AM
  5. Virtualization
  6. -8
  7. 13
  8. FEB
  9. Ransomware Hostage Rescue Guide
  10. 11:00 AM
  11. Webinar
  12. Join Erich Kron CISSP, at KnowBe4 for “Ransomware Hostage Rescue Guide
  13. Register Now »
  14. View all events »
  15.  
  16. I wrote up some rules I like to go by and wonder what you guys think of them. This list turned out longer than I expected. I hadn't realized I thought so much about what I do with virtualization before. They might be useful to others just learning.
  17.  
  18. Hard Rules (ALWAYS follow these)
  19.  
  20. 1. If you only have one use for a server, virtualization is not necessary.
  21.  
  22. 2. There is ALWAYS more than one use for a server. If you have the resources, then use them to the fullest. Virtualization allows resources to be used more fully. If you just have a file server, then virtualize it and make a firewall/router along with it, or a print server, or an authentication server, or pretty much anything. There are resources that aren’t being used, and they can be.
  23.  
  24. 3. If you’re proposing to virtualize your company, always overestimate the cost. Typically, double the money you think it will cost. Make this a habit. Chances are, you missed something, and the extra cost would be absorbed by the budget you hopefully get. It is far less costly to reputation and credibility to not use all of your budget than to have to ask for more. Also, it’s probably best to be like Scotty and quadruple the time estimate as well. It is always good to finish early, and always bad to finish late.
  25.  
  26. 4. You get what you pay for. If something is free, there is a good reason. It costs too much to go free in many cases. A free hypervisor (Hyper-V server, VMWare Vsphere Free Hypervisor, etc.) has many restrictions. Mostly, they are for learning, so more sysadmins can be made to support their stuff. If you can live with those restrictions, then more power to you. In business, those costs are usually too much. Either management is where the cost hits (Hyper-V Server) or it can’t be clustered or backed up (VMWare) or redundancy is restricted. It is simply the cost of doing business.
  27.  
  28. 5. The host is ALWAYS JUST a host. Do not deploy a Windows server as something else and then add Hyper-V as a secondary use. Deploy the Hyper-V FIRST, and then add each VM as an independent role each.
  29.  
  30. 6. There is only ONE purpose to each VM. Every single VM should have just one use and one use only. A file server just serves out files. A database server just does DB duty. A web server is just a web server. Never mix roles! Most importantly, NEVER, EVER, EVER put ANY other role on a database server.
  31.  
  32. 7. Always keep spare parts for any part of the host. Essentially, keep a whole extra machine identical to the host around that can be parted out for any part that may go bad. This is in addition to clustering. If you have a cluster of 5, keep a whole 6th machine. Budget for an extra machine, always. It is better to have an extra machine not getting used most of the time than to be down a whole node. The same goes for storage.
  33.  
  34. 8. ALWAYS keep storage separate from host. If it is either an external tray through a raid controller or a wholly separate storage appliance, keep those two separate. Never use one big machine with tons of memory and an internal raid. If kept separate, even if one part is totally down, it can be brought back up with minimal effort. If kept all together, one part going bad could bring all the VMs down for multiple days.
  35.  
  36. 9. For hosts, keep to single CPU sockets. Single processor socket hosts are less complex and have less that can go wrong. They’re also cheaper per CPU. In addition, dual socket machines can introduce extra latency for some VMs if they happen to operate on cores from two different sockets. (That can be VERY bad for performance.) It also reduces licensing costs in many cases, in that many hypervisors are licensed per socket, at least for now. This part may change in the future. If you spend $10,000 on 2 single CPU socket machines and have one die, the other is still available. If you spend $10,000 on a dual socket machine and one dies, the whole thing is down, and so are ALL of your VMs.
  37.  
  38. 10. Redundancy on the drive level is most important in storage. It is nice to have clustered storage and mirrored between RAID sets, but not everyone can afford that. When vitualizing servers, they must always be on redundant storage that can afford to lose 2 drives, but must NEVER be down more than one drive! RAID 6 on 4 drives is a minimum. Budget for this at the very least. Use RAID 10 (mirrored stripes) if going higher than 6 drives. Also, always have spare drives around in case one fails, and always swap them as soon as it is noticed. NEVER EVER USE RAID 5! If you cannot afford this, you cannot afford to have a server. Such a thing as a server with a single drive or RAID 0 SHOULD NEVER EXIST. I cannot emphasize this enough. If this means you get less storage, then so be it. It is better to have less storage than you’d like than it is to lose everything because of a failed drive.
  39.  
  40. 11. When creating VMs, always give a minimum of 2 virtual cores. Never, ever create a VM with just one core. Win Windows, Windows Update will consume a whole core, no matter how fast, and will render the VM unusable while updates are happening. A stray, misbehaving thread can hang a whole core, making the VM unusable. It’s most important in Windows, but you never know what could happen with a Linux task, so don’t take the chance. Never make a single core VM. Always default to changing the number of cores to 2 or more. Get in the habit early and never break it. Even do this with desktop virtualization. If you have a VM, it should have 2 or more cores.
  41.  
  42. 12. If your hypervisor allows for VMs to have virtual sockets along with virtual cores per socket, always use the fewest sockets you can. For example, never make a VM with 4 sockets and 1 core each. This will mess up licensing for many pieces of software, including Windows operating systems.
  43.  
  44. 13. Create VMs with the least amount of memory possible for the purpose. Unused memory just sits, and unused hardware costs money. (The spare parts situation is a matter of balance between cost and benefit.) A postfix relay would just need 512MB. A file server or domain controller can work just fine with 2GB. The hypervisor and the storage appliance or server will handle caching things, so don’t worry about that side. That being said, using too little memory can cause its own issues. So, make sure and be conscious of the state of your VMs and increase memory when needed, but only when needed. If you don’t have an automated monitoring system, that sounds like a good reason to create a new VM to me.
  45.  
  46. 14. Keep track of ALL of your VMs. Always have an ongoing inventory, and update it as soon as you create OR DELETE a VM. In addition, go over your hosts monthly to make sure all VMs are accounted for and recorded. A mystery VM appearing on a host could potentially be a major thing. You don’t want your external IP blacklisted because a spammer built a relay on your VM host and you never noticed. You also don’t want some hacker (or a current or former coworker) to build a stash of his hacking tools on your VM host. It is uncomfortable to have a boss come along and question you about why customers are unable to email you. It is VERY uncomfortable to have to tell them this situation is going to last 1 to 3 months because your IP has been blacklisted.
  47. Soft Rules (Follow these if at all possible)
  48.  
  49. 1. Keep track of memory and drive space first and foremost. In making VMs, nothing matters more than memory and drive space. Processor power doesn’t matter nearly as much in most cases. Network speed is more important than CPU power in most cases. There are limited cases where something is processor intensive and may slow down other VMs if care is not taken, but most companies don’t have to deal with this, and even those who so only have to deal with it on a limited basis. (This is a soft rule in that it fits most cases, but not all)
  50.  
  51. 2. If clustering, make sure to keep the nodes as close to the same as possible. Keep the memory amounts the same, the processors the same, and the local storage the same.
  52.  
  53. 3. If clustering, manage your memory so that you are using no more than the total memory of all of your nodes minus one. If you have a cluster of 4 machines, total up the memory of 3 machines and use no more than that. If you have a cluster of 8, then use no more memory than 7 of those. If you have a cluster of 2, then use only enough memory to fill one.
  54.  
  55. 4. Redundancy on the host level is MOST IMPORTANT. It is useful to have dual power supplies, but having 2 hosts is more important. If you have to choose between getting one host with dual power supplies or two hosts with single power supplies, choose the two hosts with single power supplies.
  56.  
  57.  
  58. 5. Multipath storage whenever possible. This goes for iSCSI, FCoE, and FC. Use multiple network routes, switches, and adapters. It is best to have 2 totally separate HBAs or CNAs rather than a single dual port HBA or CAN.
  59.  
  60. 6. Use a SAN whenever possible, preferably an isolated SAN. It doesn’t have to be Fibre Channel, but iSCSI should be kept on a separate network in any case, even if just a separate, isolated VLAN. Don’t use SAS if you can get away with it. Even in a small business, this will pay off with less down time and better security.
  61. Feel free to copy and share these as you will, just remember to keep my name attached to it, please.
  62.  
  63. Dan Gingerich, Systems Administrator
  64. Reply
  65. 18
  66. Unsubscribe
  67. 18 Replies
  68. EddieJennings
  69. Jalapeno
  70. EddieJennings Feb 7, 2018 at 11:56 AM
  71.  
  72. 1. If you only have one use for a server, virtualization is not necessary.
  73.  
  74. Why not virtualize with only one guest VM?
  75.  
  76. 2 found this helpful
  77. Unspice
  78. (3)
  79. Reply
  80.  
  81. StorageNinja
  82. Mace
  83. StorageNinja Feb 7, 2018 at 11:56 AM
  84. There is ALWAYS more than one use for a server. If you have the resources, then use them to the fullest. Virtualization allows resources to be used more fully. If you just have a file server, then virtualize it and make a firewall/router along with it, or a print server, or an authentication server, or pretty much anything. There are resources that aren’t being used, and they can be.
  85.  
  86. There are HPC use cases where you will put a single VM per host, yet still use a hypervisor as a common physical drive/firmware layer and for automation API reasons.
  87.  
  88.  
  89. 3. If you’re proposing to virtualize your company, always overestimate the cost. Typically, double the money you think it will cost. Make this a habit. Chances are, you missed something, and the extra cost would be absorbed by the budget you hopefully get. It is far less costly to reputation and credibility to not use all of your budget than to have to ask for more. Also, it’s probably best to be like Scotty and quadruple the time estimate as well. It is always good to finish early, and always bad to finish late.
  90.  
  91. Learn to budget correctly, or contract a consultancy who is familiar with the projects you do? Not being able to ask for more is symptoms of a dysfunctional organization. Padding should be at a higher level than a single project IMHO.
  92.  
  93.  
  94. 4. You get what you pay for. If something is free, there is a good reason. It costs too much to go free in many cases. A free hypervisor (Hyper-V server, VMWare Vsphere Free Hypervisor, etc.) has many restrictions. Mostly, they are for learning, so more sysadmins can be made to support their stuff. If you can live with those restrictions, then more power to you. In business, those costs are usually too much. Either management is where the cost hits (Hyper-V Server) or it can’t be clustered or backed up (VMWare) or redundancy is restricted. It is simply the cost of doing business.
  95.  
  96. Paying for management tools isn’t a bad idea, especially at scale. Having alerting, performance tracking (historical), central management, HTML5 UI’s for management etc is wroth a little coin. So is support agreements so if something blows up at 3AM you can call and get the guys in Cork to dig you out of the hole.
  97.  
  98. 5. The host is ALWAYS JUST a host. Do not deploy a Windows server as something else and then add Hyper-V as a secondary use. Deploy the Hyper-V FIRST, and then add each VM as an independent role each.
  99.  
  100. I’ll add to this. For hypervisors that do support kernel modules be installed, don’t go installing non-supported weird one off stuff.
  101.  
  102. 6. There is only ONE purpose to each VM. Every single VM should have just one use and one use only. A file server just serves out files. A database server just does DB duty. A web server is just a web server. Never mix roles! Most importantly, NEVER, EVER, EVER put ANY other role on a database server.
  103.  
  104. This is true to a point then it’s not. If I have an application that 3 people use, and the database is a 3MB SQL-Lite instance, do I REALLY need to build a 3 tier application out of it? Plenty of people put VMware Update Manager on their vCenter, or put the View Composer DB (~15MB) on the Composer VM. VM Sprawl can become a problem if you get silly with this.
  105.  
  106. 7. Always keep spare parts for any part of the host. Essentially, keep a whole extra machine identical to the host around that can be parted out for any part that may go bad. This is in addition to clustering. If you have a cluster of 5, keep a whole 6th machine. Budget for an extra machine, always. It is better to have an extra machine not getting used most of the time than to be down a whole node. The same goes for storage.
  107.  
  108. When you can get a 4 hour parts support agreement from HPE/Dell why bother keeping shelf spares on the parts? If you are in Antartica I agree, but in Houston?
  109. I do prefer to run clusters at N+1 but consider keeping the +1 Running in the cluster and VM’s distributed across all. This makes the HA event smaller. Admission Control in VMware will prevent you from overloading the cluster and keeping space to reboot stuff. Also ultra mission critical N+2 becomes more common so you can take a failure while patching a host.
  110.  
  111. 8. ALWAYS keep storage separate from host. If it is either an external tray through a raid controller or a wholly separate storage appliance, keep those two separate.
  112.  
  113. This kinda goes against HCI and what people are doing with Simplivity and vSAN etc.
  114.  
  115. Never use one big machine with tons of memory and an internal raid. If kept separate, even if one part is totally down, it can be brought back up with minimal effort. If kept all together, one part going bad could bring all the VMs down for multiple days.
  116.  
  117. I do agree be careful building too big of hosts (Or even too big of clusters). At some point you should ask if you shouldn’t not if you can as the HA events with 200 VM’s rebooting can result in a LOT of people calling your help desk, and our IT staff possibly not being able to triage things quickly.
  118.  
  119.  
  120. 9. For hosts, keep to single CPU sockets. Single processor socket hosts are less complex and have less that can go wrong. They’re also cheaper per CPU.
  121.  
  122. Huh? The big jump in pricing historically was for 4 way systems not 2 way. Unless you have MTBF stats to back up your simplicity argument I’m just going to say “fake news” and move on…
  123.  
  124. In addition, dual socket machines can introduce extra latency for some VMs if they happen to operate on cores from two different sockets. (That can be VERY bad for performance.)
  125.  
  126. Just read up on vNUMA. Note ESXi made some changes in 6.5 to make this easier (Cores and sockets being decoupled for vNUMA). http://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5/
  127.  
  128. It also reduces licensing costs in many cases, in that many hypervisors are licensed per socket, at least for now. This part may change in the future. If you spend $10,000 on 2 single CPU socket machines and have one die, the other is still available. If you spend $10,000 on a dual socket machine and one dies, the whole thing is down, and so are ALL of your VMs.
  129.  
  130. This is true for small low density clusters (3-4 hosts) but at scale it’s going to be more expensive as you increase secondary costs (motherboards, switch ports etc).
  131.  
  132. 10. Redundancy on the drive level is most important in storage. It is nice to have clustered storage and mirrored between RAID sets, but not everyone can afford that.
  133.  
  134. Actually backups are the most important thing not redundancy for most people. Availability is less important than recoverability.
  135.  
  136. When vitualizing servers, they must always be on redundant storage that can afford to lose 2 drives,
  137.  
  138. Why? If I have a non-persistent VDI farm, or I’m running Hadoop RF2 why do I care? Why not be able to customize the redundancy to the workloads needs on a per VM basis and not waste money?
  139.  
  140. but must NEVER be down more than one drive! RAID 6 on 4 drives is a minimum. Budget for this at the very least. Use RAID 10 (mirrored stripes) if going higher than 6 drives.
  141.  
  142. If I’m running cheap and deep archive backup storage why use RAID 10? If I don’t care about performance double parity is far more cost effective. When I operate at the multi-PB scale RAID 10 for my object storage is just lighting money on fire.
  143.  
  144. Also, always have spare drives around in case one fails, and always swap them as soon as it is noticed. NEVER EVER USE RAID 5! If you cannot afford this, you cannot afford to have a server.
  145.  
  146. What if my drives are BER of 10^17th power, It’s all flash, and my rebuild domain (because It’s object raid) is on average 40GB? You use a lot of absolutes without understanding the math behind why people what they do here.
  147.  
  148. Such a thing as a server with a single drive or RAID 0 SHOULD NEVER EXIST.
  149. I cannot emphasize this enough. If this means you get less storage, then so be it. It is better to have less storage than you’d like than it is to lose everything because of a failed drive.
  150.  
  151. Hadoop, No-SQL and other things that replicate themselves love to use RAID 0.
  152.  
  153. 11. When creating VMs, always give a minimum of 2 virtual cores. Never, ever create a VM with just one core.
  154.  
  155. Why? A domain Controller doesn’t need 2 Cores for a shop with 50 users.
  156.  
  157. Win Windows, Windows Update will consume a whole core, no matter how fast, and will render the VM unusable while updates are happening. A stray, misbehaving thread can hang a whole core, making the VM unusable.
  158.  
  159. Frankly I just don’t see this that often in modern Windows VM’s providing a native service and (single one at that). For app servers? Fine. For a windows server providing DHCP only? Log a ticket with Microsoft if you see that.
  160.  
  161. It’s most important in Windows, but you never know what could happen with a Linux task, so don’t take the chance. Never make a single core VM. Always default to changing the number of cores to 2 or more. Get in the habit early and never break it. Even do this with desktop virtualization. If you have a VM, it should have 2 or more cores.
  162.  
  163. If it’s a desktop VM that runs a single single threaded app and has low overhead for protocol, why overload the scheduler?
  164.  
  165. 12. If your hypervisor allows for VMs to have virtual sockets along with virtual cores per socket, always use the fewest sockets you can. For example, never make a VM with 4 sockets and 1 core each. This will mess up licensing for many pieces of software, including Windows operating systems.
  166.  
  167. This has been decoupled a bit in ESXi 6.5 (I can’t speak for other). See Frank’s blog. http://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5/
  168.  
  169. 13. Create VMs with the least amount of memory possible for the purpose. Unused memory just sits, and unused hardware costs money. (The spare parts situation is a matter of balance between cost and benefit.) A postfix relay would just need 512MB. A file server or domain controller can work just fine with 2GB. The hypervisor and the storage appliance or server will handle caching things, so don’t worry about that side. That being said, using too little memory can cause its own issues. So, make sure and be conscious of the state of your VMs and increase memory when needed, but only when needed. If you don’t have an automated monitoring system, that sounds like a good reason to create a new VM to me.
  170.  
  171. Something like 30% of VMware shops overcommit memory. It’s less common than it used to be, but it does happen. Enabling and SALTing TPS, using the Balloon Driver can mitigate most of the negative while giving more room for burst on apps. DRS also can predict load to memory and keep hosts from causing issues with each other (A billion worth of R&D into a feature means it MIGHT be useful sometimes!)
  172.  
  173. 14. Keep track of ALL of your VMs. Always have an ongoing inventory, and update it as soon as you create OR DELETE a VM. In addition, go over your hosts monthly to make sure all VMs are accounted for and recorded. A mystery VM appearing on a host could potentially be a major thing. You don’t want your external IP blacklisted because a spammer built a relay on your VM host and you never noticed. You also don’t want some hacker (or a current or former coworker) to build a stash of his hacking tools on your VM host. It is uncomfortable to have a boss come along and question you about why customers are unable to email you. It is VERY uncomfortable to have to tell them this situation is going to last 1 to 3 months because your IP has been blacklisted.
  174.  
  175. I’d argue tracking what the are doing (Using Logging like LogInisght, and at a network level using Netflow using stuff like NSX and vRNI) is more important. If you have NSX policies that are auto applied to VM’s with an explicit deny a “rogue” VM will not be able to do anything interesting because of micro segmentation.
  176.  
  177. Soft Rules (Follow these if at all possible)
  178. 1. Keep track of memory and drive space first and foremost. In making VMs, nothing matters more than memory and drive space. Processor power doesn’t matter nearly as much in most cases.
  179.  
  180. You sir have never run a web application farm.
  181. Go grab a copy of the Host Resources Deep Dive book.
  182. https://www.rubrik.com/blog/vmware-vsphere-ebook/
  183.  
  184. Network speed is more important than CPU power in most cases.
  185.  
  186. Latency or throughput? Can you clarify this statement…
  187.  
  188. There are limited cases where something is processor intensive and may slow down other VMs if care is not taken, but most companies don’t have to deal with this, and even those who so only have to deal with it on a limited basis. (This is a soft rule in that it fits most cases, but not all)
  189.  
  190. This is why you turn on DRS and listen to vROPS reports of noisy neighbors.
  191.  
  192. 2. If clustering, make sure to keep the nodes as close to the same as possible. Keep the memory amounts the same, the processors the same, and the local storage the same.
  193.  
  194. Common sense, but EVC exists for a reason. Buying a 12th generation host when it's about to go end of sale or support to meet needs for 6th months isn't a great idea either.
  195.  
  196. 3. If clustering, manage your memory so that you are using no more than the total memory of all of your nodes minus one. If you have a cluster of 4 machines, total up the memory of 3 machines and use no more than that. If you have a cluster of 8, then use no more memory than 7 of those. If you have a cluster of 2, then use only enough memory to fill one.
  197.  
  198. If you want to do this just turn on EVC and DRS as it’s smarter than you and will size for “Slot sizes” and other things you are missing here. You could have situations where the lego blocks don’t cleanly fit into N-1.
  199.  
  200.  
  201. 4. Redundancy on the host level is MOST IMPORTANT. It is useful to have dual power supplies, but having 2 hosts is more important. If you have to choose between getting one host with dual power supplies or two hosts with single power supplies, choose the two hosts with single power supplies.
  202.  
  203. I’d argue again, backups and an offsite copy of them (3:2:1) is most important. Although Some would argue the question of “What is best in life” is better responded to this way. https://www.youtube.com/watch?v=6PQ6335puOc
  204.  
  205.  
  206.  
  207.  
  208. 5. Multipath storage whenever possible. This goes for iSCSI, FCoE, and FC. Use multiple network routes, switches, and adapters. It is best to have 2 totally separate HBAs or CNAs rather than a single dual port HBA or CAN.
  209.  
  210. Why use switches if you can direct connect at small scale DAS? How many times have you seen a HBA fail and not the entire host? Also I tend to avoid using FCoE at all unless I’m desperate.
  211.  
  212. 6. Use a SAN whenever possible, preferably an isolated SAN. It doesn’t have to be Fibre Channel, but iSCSI should be kept on a separate network in any case, even if just a separate, isolated VLAN. Don’t use SAS if you can get away with it. Even in a small business, this will pay off with less down time and better security.
  213.  
  214. Can you explain how a SAS 8088 DAS connection has worse security than an iSCSI or FC Network that lacks in flight encryption?
  215.  
  216. Feel free to copy and share these as you will, just remember to keep my name attached to it, please.
  217. Dan Gingerich, Systems Administrator
  218.  
  219. Dan we should argue over this at Spiceworld over beers. Edited Feb 7, 2018 at 12:54 PM
  220.  
  221. 4 found this helpful
  222. Unspice
  223. (7)
  224. Reply
  225.  
  226. Danielgingerich
  227. Serrano
  228. OP
  229. Danielgingerich Feb 7, 2018 at 11:59 AM
  230.  
  231. EddieJennings wrote:
  232.  
  233. Why not virtualize with only one guest VM?
  234. + expand
  235.  
  236. Read rule 2. It's kind of a humorous place to start.
  237.  
  238. 0 of 1 found this helpful
  239. Spice
  240. Reply
  241.  
  242. EddieJennings
  243. Jalapeno
  244. EddieJennings Feb 7, 2018 at 12:02 PM
  245.  
  246. I did, albeit after I asked my question, which leads me to wonder why even have rule 1.
  247.  
  248. Was this post helpful?
  249. Spice
  250. (1)
  251. Reply
  252.  
  253. Scott Alan Miller
  254. Pure Capsaicin
  255. Scott Alan Miller Feb 7, 2018 at 12:06 PM
  256.  
  257. Niagara Technology Group (NTG) is an IT service provider.
  258.  
  259. Danielgingerich wrote:
  260.  
  261. Hard Rules (ALWAYS follow these)
  262.  
  263. 1. If you only have one use for a server, virtualization is not necessary.
  264.  
  265. This is completely wrong. Virtualization is ALWAYS necessary. That you have only one or two servers has nothing to do with it. This is a dead horse, we've covered this so much for so long. This was a discussion around 2007, it's been more than a decade since the last remnants of "it's okay not to virtualize" or getting virtualization and consolidation confused should have died out.
  266.  
  267. http://www.smbitjournal.com/2015/04/virtualizing-even-a-single-server/
  268.  
  269.  
  270. 3. If you’re proposing to virtualize your company, always overestimate the cost.
  271.  
  272. This is just bad. Virtualization is free itself. This is just bad estimation. If you have to do this, you have significant problems somewhere either in politics or the estimation process. Anytime you intentionally do this, it means you have something that should be fixed rather than providing false estimates.
  273.  
  274.  
  275. 4. You get what you pay for. If something is free, there is a good reason. It costs too much to go free in many cases. A free hypervisor (Hyper-V server, VMWare Vsphere Free Hypervisor, etc.) has many restrictions.
  276.  
  277. Again, totally backwards. "You get what you pay for" is nonsense in the real world. We also say "the best things in life are free." There aren't restrictions on those free hypervisors, except ESXi. Basically, you see paying money as value. So anyone who overcharges you is better than anyone that donates time or gives you good value. This is terrible logic and should never be used in business.
  278.  
  279. 6. There is only ONE purpose to each VM. Every single VM should have just one use and one use only. A file server just serves out files. A database server just does DB duty. A web server is just a web server. Never mix roles! Most importantly, NEVER, EVER, EVER put ANY other role on a database server.
  280.  
  281. This is "often true" but is not a hard rule. A hard rule would imply best practice, this is at best a rule of thumb. There are TONS of times that you should combine roles. Like AD, DNS and DHCP. Or application and database on the same VM. In the SMB, it's likely most of the time, rather than once in a while.
  282.  
  283.  
  284. 7. Always keep spare parts for any part of the host. Essentially, keep a whole extra machine identical to the host around that can be parted out for any part that may go bad.
  285.  
  286. Again, cases where this might be okay, but very rarely. Nothing in IT, nothing ever, is an "always do" like this. For something this extreme, it's not even good 50% of the time. This is a maybe 1% of the time kind of thing. If you did all this, why not do HA with it instead of just having it as parts, as well? Not the best use of what you have on hand.
  287.  
  288.  
  289. 8. ALWAYS keep storage separate from host.
  290.  
  291. While nothing is "always" this is pretty close to being the opposite. In all but super rare cases, you keep storage WITH hosts. It is cheaper, safer, and faster. This is one of the most important mistakes that people make that we spend time correcting. Other than RAID decisions, no single thing has been more often addressed here on SW in the last five years.
  292.  
  293.  
  294. 9. For hosts, keep to single CPU sockets.
  295.  
  296. There are loads of cases where this makes sense, but just as many where it doesn't. Like everything in IT this should be "evaluate your needs and do the right thing." One and two socket systems are the most logical most of the time, with two being the biggest overall winner. But there are loads of cases for four, eight, sixteen, even 256 CPU systems. there is no basis for such a wild claim as one socket systems being the only one plausible socket count in the industry.
  297.  
  298.  
  299. 10. Redundancy on the drive level is most important in storage. It is nice to have clustered storage and mirrored between RAID sets, but not everyone can afford that.
  300.  
  301. This is kinda true, but is anything but a hard and fast rule. Every major vendor agrees that this is outdated and wrong (as a rule.) It has its place, but below the 50% of the time mark.
  302.  
  303.  
  304. 11. When creating VMs, always give a minimum of 2 virtual cores.
  305.  
  306. Actually the majority should be just one. You want to do fewer cores than people think, not more. Never do you go to more than one without a reason. Often you need more than one, but not most of the time. Never could this be a hard rule, it's not even a valid rule of thumb.
  307.  
  308.  
  309. 12. If your hypervisor allows for VMs to have virtual sockets along with virtual cores per socket, always use the fewest sockets you can.
  310.  
  311. Just no. This is purely for reporting licensing to the VM and there is no IT needs, concerns or rules about this whatsoever. This is all a legal issue having to do with licensing, nothing else. This rule is pointless and simply wrong.
  312.  
  313.  
  314. 3. If clustering, manage your memory so that you are using no more than the total memory of all of your nodes minus one.
  315.  
  316. This is good to consider, but only applies when talking about HA clustering, not clustering in general. your rule is too broad and doesn't take into consideration the type of cluster.
  317.  
  318. 2 of 3 found this helpful
  319. Unspice
  320. (2)
  321. Reply
  322.  
  323. Dashrender
  324. Datil
  325. Dashrender Feb 7, 2018 at 12:13 PM
  326.  
  327. StorageNinja wrote:
  328.  
  329. Wrong wrong wrong :)
  330.  
  331. OMG - You are so right - the OP is so wrong wrong wrong. I had to stop reading after #8, my mind was completely blown - possibly the most bad information in a single post ever.
  332.  
  333. 2 found this helpful
  334. Spice
  335. (3)
  336. Reply
  337.  
  338. Scott Alan Miller
  339. Pure Capsaicin
  340. Scott Alan Miller Feb 7, 2018 at 12:14 PM
  341.  
  342. Niagara Technology Group (NTG) is an IT service provider.
  343.  
  344. I was quoting so many things I accidentally hit submit before being done.... sorry for the second post....
  345.  
  346.  
  347. 4. Redundancy on the host level is MOST IMPORTANT. It is useful to have dual power supplies, but having 2 hosts is more important.
  348.  
  349. I realize this is a soft rule here, but this isn't really a rule at all. As a general rule, it should be the opposite. You should not be paying the high cost for node redundancy if you don't pay the low cost for host reliability most of the time, it's just not a good use of money. Like everything, evaluate your specific needs. The idea is interesting, but it can't be a rule.
  350.  
  351.  
  352. 5. Multipath storage whenever possible. This goes for iSCSI, FCoE, and FC.
  353.  
  354.  
  355. This should be when sensible, not when possible. It's always "possible", but not always a good idea.
  356.  
  357.  
  358. 6. Use a SAN whenever possible, preferably an isolated SAN.
  359.  
  360. One would hope that it goes without saying that this is the worst possible idea for a rule. SAN is the least likely thing you want as storage for a system. Of course it has its use cases, but they are extremely rare and getting rarer by the day. 99% of companies should never even entertain the idea of a SAN, let alone decide on one. Of the remaining 1% that should evaluate them, only a few should result in getting one. In the SMB market, it should be more like .1%, it's hard to state just how rare this should be today.
  361.  
  362. Danielgingerich wrote:
  363. Feel free to copy and share these as you will, just remember to keep my name attached to it, please.
  364.  
  365. Dan Gingerich, Systems Administrator
  366.  
  367. I hate to say it, but this feels like the most definitive collection of virtualization myths, mistakes and "what not to do" I've ever seen collected into one place. There is some good discussion points, and you definitely got a few things right. But I think you should run each of these by the community one by one. Nearly everyone is has been covered scores, if not hundreds, of times and have been delved into very thoroughly and your resulting guidance here relies on either disagreeing with accepted industry knowledge, or not being aware that it is out there.
  368.  
  369. I assume you meant this to really be a definitive guide, and you certainly put in some great effort. But I think that it is lacking the necessary research before hand.
  370.  
  371. 1 found this helpful
  372. Unspice
  373. (1)
  374. Reply
  375.  
  376. Scott Alan Miller
  377. Pure Capsaicin
  378. Scott Alan Miller Feb 7, 2018 at 12:15 PM
  379.  
  380. Niagara Technology Group (NTG) is an IT service provider.
  381.  
  382. Danielgingerich wrote:
  383.  
  384. Read rule 2. It's kind of a humorous place to start.
  385. + expand
  386.  
  387. That conflicts with rule 6
  388.  
  389. 1 found this helpful
  390. Unspice
  391. (1)
  392. Reply
  393.  
  394. Joffles
  395. Datil
  396. Joffles Feb 7, 2018 at 12:23 PM
  397.  
  398. i stopped reading about halfway through. but most of these are wrong and go against real industry best practices. not to mention #2 and #6 seem to contradict. I agree with #5 though if that helps lol.
  399.  
  400. im sure someone will come through and methodically point out how wrong most of these are, so ill just wait for them.
  401.  
  402. [Image: //static.spiceworks.com/shared/post/0029/3744/giphy.gif]
  403.  
  404. 1 found this helpful
  405. Spice
  406. (3)
  407. Reply
  408.  
  409. tfl
  410. Mace
  411. tfl Feb 7, 2018 at 12:24 PM
  412.  
  413. You need to come on my Windows Virtualisation courses.
  414.  
  415. As an example: number 11. Nonsense. For a lot of servers, a single processor is just fine. Windows update runs using BITS (which only downloads when the net bandwidth allows it and in the background on a lower priority thread). An update should run in the background and be relatively unnoticed once you get the first set of updates out of the way! Windows has mechanisms to deal with runaway threads, but those kinds of things are not overly common. I would always recommend you start with one CPU and measure. If the virtual server is running at less than 75% on a sustained basis, then it doesn't need more CPUs.
  416.  
  417. And as for number 12 - I have no clue what you are talking about. If you have, for example, a dual proc, 6 core Xeon with Hyperthreading you have two physical processors, 12 physical cores and 24 logical cores thanks to hyperthreading. When you create a VM, you just specify the number of virtual processors to use. On this box, you can specify up to 24 processors for the VM.If you try to specify more in the UI, the VM doesn't start. There is no concept of virtual sockets. The VM starts fine with 24 virtual processors and the host is responsive as is the VM.
  418.  
  419. Was this post helpful?
  420. Spice
  421. Reply
  422.  
  423. Danielgingerich
  424. Serrano
  425. OP
  426. Danielgingerich Feb 7, 2018 at 12:25 PM
  427.  
  428. Dashrender wrote:
  429.  
  430. OMG - You are so right - the OP is so wrong wrong wrong. I had to stop reading after #8, my mind was completely blown - possibly the most bad information in a single post ever.
  431. + expand
  432.  
  433. Why? I put reasons into most of those rules as to why. I'd like to hear why anyone has criticism of a rule in that list.
  434.  
  435. 0 of 1 found this helpful
  436. Spice
  437. Reply
  438.  
  439. Danielgingerich
  440. Serrano
  441. OP
  442. Danielgingerich Feb 7, 2018 at 12:37 PM
  443.  
  444. tfl wrote:
  445.  
  446. You need to come on my Windows Virtualisation courses.
  447.  
  448. As an example: number 11. Nonsense. For a lot of servers, a single processor is just fine. Windows update runs using BITS (which only downloads when the net bandwidth allows it and in the background on a lower priority thread). An update should run in the background and be relatively unnoticed once you get the first set of updates out of the way! Windows has mechanisms to deal with runaway threads, but those kinds of things are not overly common. I would always recommend you start with one CPU and measure. If the virtual server is running at less than 75% on a sustained basis, then it doesn't need more CPUs.
  449.  
  450. And as for number 12 - I have no clue what you are talking about. If you have, for example, a dual proc, 6 core Xeon with Hyperthreading you have two physical processors, 12 physical cores and 24 logical cores thanks to hyperthreading. When you create a VM, you just specify the number of virtual processors to use. On this box, you can specify up to 24 processors for the VM.If you try to specify more in the UI, the VM doesn't start. There is no concept of virtual sockets. The VM starts fine with 24 virtual processors and the host is responsive as is the VM.
  451.  
  452. For #11. I've seen far, far too many cases where a single core VM was rendered unresponsive for various reasons, including Windows Updates. Windows Updates takes at least three times as long as a dual core on the exact same VM. You cannot deny it. It is so easily reproducible. Check it out for yourself. Make a single core OS, take a snapshot of it, then run it through updates and time. Also, try to do ANYTHING with it while it is searching for updates. It becomes unusable. Then restore the snapshot, reconfigure it for dual cores, and run Windows Update again. It'll take a third of the time and the system will still be usable while it is searching for updates.
  453.  
  454. For #12, VMWare has the configuration options of virtual sockets and virtual core per socket. I had a coworker set up a VM with 4 single core sockets and then wondered why it took 2 license codes for Windows Server 2008r2 Standard (MSDN, so no big deal) to activate it and use it. Windows Server 2008r2 and 2012r2 are licensed by sockets, and Standard only covers a license for up to 2 sockets. So, it takes 2 licenses for a 4 socket machine. He could have avoided it entirely with just a single socket with 4 cores. There is no reason to use many sockets and few cores. There are many other programs that are similar, including VMWare.
  455.  
  456. 0 of 2 found this helpful
  457. Spice
  458. Reply
  459.  
  460. Scott Alan Miller
  461. Pure Capsaicin
  462. Scott Alan Miller Feb 7, 2018 at 12:39 PM
  463.  
  464. Niagara Technology Group (NTG) is an IT service provider.
  465.  
  466. Danielgingerich wrote:
  467.  
  468. Why? I put reasons into most of those rules as to why. I'd like to hear why anyone has criticism of a rule in that list.
  469. + expand
  470.  
  471. My point by point analysis took a few minutes to get added. It is available now.
  472.  
  473. The issue is that nearly every rule you have here has been discussed ad nauseum in the community. And, of course, it is completely reasonable to disagree with those discussions or the collective decisions of the community. But when you do so, you should acknowledge them at the very least to make it clear that you are aware of the standard approaches and then address why you feel that they are wrong. The manner in which you posted, you primarily posted advice that contradicts all of the standard, accepted rules or thumbs or best practices; but does so without acknowledging that you are contradicting them or explaining why you feel that they are wrong.
  474.  
  475. I think a lot of your rules, if reworded to "consider the value if...." would be great. Like "consider if single socket servers are best for you" or "dont' just rule out a SAN because it rarely applies, still make sure it isn't right for you" or "be aware when clustering that you might have value in having nodes be similar". All of those are great things to be aware of and consider. But as rules, the only rule should be "be aware of the consequences and always evaluate for your unique environment" rather than the rule being the answer without consideration for the environmental needs. Which is really what many of those rules feel like they are a response to. For example, many people "just assume" that dual socket systems are the way to go and never consider anything else. That's wrong. By all means, tell them to consider single sockets... as well as quad sockets and other options. But instead, you repeat the mistake of saying "do this one thing", you just shift what that one thing is.
  476.  
  477. 3 found this helpful
  478. Unspice
  479. (2)
  480. Reply
  481.  
  482. Jared Busch
  483. Datil
  484. Jared Busch Feb 7, 2018 at 12:44 PM
  485.  
  486. Bundy & Associates is an IT service provider.
  487.  
  488. Danielgingerich wrote:
  489. Feel free to copy and share these as you will, just remember to keep my name attached to it, please.
  490.  
  491. Dan Gingerich, Systems Administrator
  492.  
  493. Only as an example of what to not do. This is a mess. I think all of my points have been covered by the other replies.
  494.  
  495. 3 found this helpful
  496. Unspice
  497. (5)
  498. Reply
  499.  
  500. Scott Alan Miller
  501. Pure Capsaicin
  502. Scott Alan Miller Feb 7, 2018 at 12:48 PM
  503.  
  504. Niagara Technology Group (NTG) is an IT service provider.
  505.  
  506. Danielgingerich wrote:
  507.  
  508. For #11. I've seen far, far too many cases where a single core VM was rendered unresponsive for various reasons, including Windows Updates.
  509.  
  510. Using this logic, you could have just as easily said "never use Windows" or "never run updates." It's not a problem specifically caused by a VM having just one vCPU. Most of us run the majority of our workloads on single vCPU and never see these kinds of problems. This is a combination of many factors, and while it might be worth considering the value of having another vCPU for this reason if you have those factors, it wouldn't create a blanket rule to handle this. That's not the correct basis for a rule. Also worth noting, VMs get vCPUs, not cores. This might seem pedantic, and it is if you are acutely aware of the differences already and aren't confused. But the average IT person reading this doesn't understand the differences and really do think that vCPU and cores are directly related so this wording leads them astray quite a bit.
  511.  
  512. Danielgingerich wrote:
  513.  
  514.  
  515. For #12, VMWare has the configuration options of virtual sockets and virtual core per socket. I had a coworker set up a VM with 4 single core sockets and then wondered why it took 2 license codes for Windows Server 2008r2 Standard (MSDN, so no big deal) to activate it and use it. Windows Server 2008r2 and 2012r2 are licensed by sockets, and Standard only covers a license for up to 2 sockets. So, it takes 2 licenses for a 4 socket machine. He could have avoided it entirely with just a single socket with 4 cores. There is no reason to use many sockets and few cores. There are many other programs that are similar, including VMWare.
  516.  
  517. This is just an anecdote where one person did one thing wrong. What if the software in question did the opposite and charged by cores, but NOT by sockets? Then your advice would be opposite. You are assuming that everyone is using Windows 2008 R2 here, and that licensing is determined in that one way, and that you should report via the interface a specific thing. While these things might be valid for your one specific use case, they are not a rule and have no validity in the general case.
  518.  
  519. In most cases you can use any combination of these things that you want, they are just a way that the interface reports. In cases where it affects licensing, you must do what is legally required by your software. IT has really no say here as to what it should do, it should do whatever is legally and ethically appropriate. So no rule of "always do X" should ever be made, and it is for this very reason that this option exists. If your logic was sound, no vendor should have made such a silly option available to end users; yet they all do for important reasons.
  520.  
  521. You say that there is no reason to use more sockets rather than cores, but what is the basis for this statement? How did you determine that the rest of us don't need that for whatever reason - generally to meet licensing requirements?
  522.  
  523. 1 found this helpful
  524. Spice
  525. (1)
  526. Reply
  527.  
  528. Joffles
  529. Datil
  530. Joffles Feb 7, 2018 at 12:49 PM
  531.  
  532. your rules seem to be almost entirely anecdotal and based on nothing other than your own experiences. while these may have helped you, i can guarantee that they would not be beneficial in my environment.
  533.  
  534. Was this post helpful?
  535. Spice
  536. (1)
  537. Reply
  538.  
  539. StorageNinja
  540. Mace
  541. StorageNinja Feb 7, 2018 at 12:55 PM
  542.  
  543. Danielgingerich wrote:
  544.  
  545. Why? I put reasons into most of those rules as to why. I'd like to hear why anyone has criticism of a rule in that list.
  546. + expand
  547.  
  548. I just put that as a placeholder so I could collect my thoughts. See the updated list of rebuttal.
  549.  
  550. 1 found this helpful
  551. Spice
  552. (1)
  553. Reply
  554.  
  555. Tim_G
  556. Cayenne
  557. Tim_G Feb 7, 2018 at 12:56 PM
  558.  
  559. Danielgingerich wrote:
  560.  
  561. For #11. I've seen far, far too many cases where a single core VM was rendered unresponsive for various reasons, including Windows Updates. Windows Updates takes at least three times as long as a dual core on the exact same VM. You cannot deny it. It is so easily reproducible. Check it out for yourself. Make a single core OS, take a snapshot of it, then run it through updates and time. Also, try to do ANYTHING with it while it is searching for updates. It becomes unusable. Then restore the snapshot, reconfigure it for dual cores, and run Windows Update again. It'll take a third of the time and the system will still be usable while it is searching for updates.
  562. + expand
  563.  
  564. So you create a rule to waste vCPUs because you assume everyone's Virtualization environment was done poorly and exclusively consists of bad Windows Server implementations?
  565.  
  566. I don't think so.
  567.  
  568. Reply
  569. Manage
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!