Answers: <p>There are several related system engineering trade-offs and choices involved in answering your question. It may be helpful going forward to tackle this question by first prioritizing your objectives and then making the selection and trade-off decisions about VLAN structure, cluster(pod) sizes, etc. to decide which options give you the most bang for the buck in vertical scaling. </p>
  
  <p>For example, you didn't explain how cpu intensive your web apps are or how much load balancing (based on the front end API management and back end messaging) you expect you will need. While load balancers may not seem relevant to your Docker/K8s design question, the impact this can have on how you size your cluster nodes is obvious if you consider what impact too many nodes and a poorly distributed or overworked load balancer could have on your VLAN design.  </p>
  
  <p>The 'one app per VM' design you described suggests your app's workloads are pretty big (for an 8GB VM). Again need more info to delve into this more deeply, but assigning a DB VM per App VM seems a bit wasteful in terms of K8s worker/manager efficiency unless there's a severe reliability and resiliency requirement.   </p>
  
  <p>Next, what are your options to replace the magnetic HD with SSD? Costs for 100GB and 500GB SSD have dropped significantly and replacing your mag HD with SSD could certainly give your clusters a good deal of disk performance headroom when you scale up. In addition to performance, despite the added costs, overall system reliability (MTTF, MTTR) will increase dramatically. New SSD drives have 6GB data channels which is probably at least double what your mag HD have now. In building a Docker/K8s cluster of any size, disk channel bandwidth and processor core count can cover a multitude of design sins.      </p>
  
  <p>Finally, not sure what your project delivery timeframe is for this, but it might help your thinking all this over and making the best choices if you can take a step back and model this with SysML (using MS Visio) and look at your design and then apply Architectural Tradeoff Analysis Method. </p>
  
  <p>ATAM and the theory behind it, despite its name, is really rather simple both in theory and in practice. ATAM gets its name because it not only
  reveals how well an architecture satisfies particular quality goals (such as performance or "modifiability" or scaling in your case), but it also provides insight into how those  goals interact with each other — how they
  trade off against each other. Doing ATAM upfront does point out critical design decisions with the most far-reaching consequences and are the most difficult to change after a system has been implemented. </p>
  
  <p>SysML and ATAM is also a kind of insurance policy against painting yourself into a corner when you are asked to cost justify your design choices or forecast TCO when a change in either the web app design or your VMWare infrastructure occurs in the future.  </p>
  
  <p><a href="https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf" rel="nofollow noreferrer">ATAM info here >>></a>  </p>
  
  <p><a href="http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE-060524-low_res.pdf" rel="nofollow noreferrer">SysML info here >>></a> </p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-08T15:02:51.190Z
Answers: 2018-03-08T16:00:23.950Z
Answers: 2018-03-08T16:00:23.950Z
Answers: Pinnacle Systems Group
Body: <p>I'm designing a web apps and web services hosting platform using kubernetes clusters of VMs running docker containers (web services, web apps, databases).</p>
  
  <p>This application hosting platform will be set on top of an existing VMWare infrastructure. We have 3 physical hosts powered by ESX.</p>
  
  <p>Today a network of some 10s of VLANs runs approx 100 to 200 virtual servers with ~1 to 4 cores and 1 to 8 GB of RAM, with some 10s of GB of hard disks (classical HD, no-SSD).</p>
  
  <p>Today our system is managed the old way, with named VM servers running one app or one database.</p>
  
  <p>What I have to do is to create a new VLAN of some VMs (maybe 5 or 6 in a first time), running a kubernetes cluster to host web applications, web services and databases docker containers (developed and deployed by our gitlab on-premise instance).</p>
  
  <p>Once this VLAN and kubernetes cluster will be up and running, tested for a while and validated by me and the direction, the project is to extend this architecture to the whole VMWare infrastructure, VLAN after VLAN.</p>
  
  <p>The question is, how to dimension (vertical scaling) the underlying linux VMs composing the kubernetes cluster ?</p>
  
  <p>How much cpus, RAM and disk space should I allocate by virtual host to be able to maximize the benefits of horizontal scaling allowed by the containerized architecture, the nginx load balancing and the mongodb sharding ?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-08T13:33:43.937Z
Comments: [Related question if not duplicate](https://devops.stackexchange.com/questions/1885/vm-hosts-single-large-host-or-few-smaller-hosts)
Comments: Tensibai
Tags: <docker><kubernetes><load-balance><vmware>
Title: How to dimmension VMWare VM linux servers to run kubernetes container clusters?
UserDisplayName: Rémi Becheras
ThreadText: # How to dimmension VMWare VM linux servers to run kubernetes container clusters?
  
  (Asked by: username_0 on 2018-03-08)
  
  I'm designing a web apps and web services hosting platform using kubernetes clusters of VMs running docker containers (web services, web apps, databases).
  
  This application hosting platform will be set on top of an existing VMWare infrastructure. We have 3 physical hosts powered by ESX.
  
  Today a network of some 10s of VLANs runs approx 100 to 200 virtual servers with ~1 to 4 cores and 1 to 8 GB of RAM, with some 10s of GB of hard disks (classical HD, no-SSD).
  
  Today our system is managed the old way, with named VM servers running one app or one database.
  
  What I have to do is to create a new VLAN of some VMs (maybe 5 or 6 in a first time), running a kubernetes cluster to host web applications, web services and databases docker containers (developed and deployed by our gitlab on-premise instance).
  
  Once this VLAN and kubernetes cluster will be up and running, tested for a while and validated by me and the direction, the project is to extend this architecture to the whole VMWare infrastructure, VLAN after VLAN.
  
  The question is, how to dimension (vertical scaling) the underlying linux VMs composing the kubernetes cluster ?
  
  How much cpus, RAM and disk space should I allocate by virtual host to be able to maximize the benefits of horizontal scaling allowed by the containerized architecture, the nginx load balancing and the mongodb sharding ?
  
  **Tags:** docker, kubernetes, load-balance, vmware
  
  > **Comments:**
  > **username_1**: [Related question if not duplicate](https://devops.stackexchange.com/questions/1885/vm-hosts-single-large-host-or-few-smaller-hosts)  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-03-08. Score: 1
  
  There are several related system engineering trade-offs and choices involved in answering your question. It may be helpful going forward to tackle this question by first prioritizing your objectives and then making the selection and trade-off decisions about VLAN structure, cluster(pod) sizes, etc. to decide which options give you the most bang for the buck in vertical scaling.
  
  For example, you didn't explain how cpu intensive your web apps are or how much load balancing (based on the front end API management and back end messaging) you expect you will need. While load balancers may not seem relevant to your Docker/K8s design question, the impact this can have on how you size your cluster nodes is obvious if you consider what impact too many nodes and a poorly distributed or overworked load balancer could have on your VLAN design.
  
  The 'one app per VM' design you described suggests your app's workloads are pretty big (for an 8GB VM). Again need more info to delve into this more deeply, but assigning a DB VM per App VM seems a bit wasteful in terms of K8s worker/manager efficiency unless there's a severe reliability and resiliency requirement.
  
  Next, what are your options to replace the magnetic HD with SSD? Costs for 100GB and 500GB SSD have dropped significantly and replacing your mag HD with SSD could certainly give your clusters a good deal of disk performance headroom when you scale up. In addition to performance, despite the added costs, overall system reliability (MTTF, MTTR) will increase dramatically. New SSD drives have 6GB data channels which is probably at least double what your mag HD have now. In building a Docker/K8s cluster of any size, disk channel bandwidth and processor core count can cover a multitude of design sins.
  
  Finally, not sure what your project delivery timeframe is for this, but it might help your thinking all this over and making the best choices if you can take a step back and model this with SysML (using MS Visio) and look at your design and then apply Architectural Tradeoff Analysis Method.
  
  ATAM and the theory behind it, despite its name, is really rather simple both in theory and in practice. ATAM gets its name because it not only
  reveals how well an architecture satisfies particular quality goals (such as performance or "modifiability" or scaling in your case), but it also provides insight into how those goals interact with each other — how they
  trade off against each other. Doing ATAM upfront does point out critical design decisions with the most far-reaching consequences and are the most difficult to change after a system has been implemented.
  
  SysML and ATAM is also a kind of insurance policy against painting yourself into a corner when you are asked to cost justify your design choices or forecast TCO when a change in either the web app design or your VMWare infrastructure occurs in the future.
  
  [ATAM info here >>>](https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf)
  
  [SysML info here >>>](http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE-060524-low_res.pdf)
  
  
  ---
  
  