Mike We know how to modify the CPU/memory dynamically. The issue is how do we get the docker components to signal that they are about to deploy more workload than the current memory size can handle so we can grow it. Phil
Sent from my iPhone > On Oct 27, 2016, at 9:52 PM, Mike Friesenegger <mi...@suse.com> wrote: > > Have you looked at cpuplugd - > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_cpuplugdcmd.html > - which uses a set of rules to dynamically enable or disable CPUs and > also dynamically add or remove memory. > > Mike Friesenegger > >> On 10/27/2016 06:56 PM, PHILIP TULLY wrote: >> The issue here is we have multiple docker engines on multiple lpars ( >> we still think from an economics and manageability point of view that >> under VM is better than on the metal). >> We have been doing the testing to have one engine pick up the workload >> form another that has failed, this works. >> We are still trying to make the environment more flexible. These >> docker engine VMs are sized at 60G and 8 vcpu but can grow (without >> ipl) to 120G and 16 vcpu's. It is the automation piece to exploit >> the flexibility of the platform that we need to figure out. Yes, we >> can define full and "waste" resources but at these sizes the resources >> are big. >> >> >> >>> On Tue, Oct 25, 2016 at 04:57 PM, R P Herrold wrote: >>> >>>> On Tue, 25 Oct 2016, PHILIP TULLY wrote: >>>> >>>> We are looking to implement Docker on Z, as we have begun the testing >>>> part of the issue is to be able to grow a docker engine and growing it >>>> dynamically based on it's current needs especially when a node in the >>>> Docker cluster fails. >>>> >>>> So the question is does anyone see a way for the VM system to see the >>>> memory resource grow, which would allow me to add more dynamically. >>> >>> I thought one point of Docker was to have 'fast to spin up' >>> instances, ready to spin up, which then pulled in ephemeral >>> data from a back end persistent store, so that a swarm of them >>> handled load spikes, and once the spike passes, that the >>> excess units are shut down >>> >>> -- Russ herrold >>> >>> ---------------------------------------------------------------------- >>> For LINUX-390 subscribe / signoff / archive access instructions, >>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 >>> or visit >>> http://www.marist.edu/htbin/wlvindex?LINUX-390 >>> ---------------------------------------------------------------------- >>> For more information on Linux on System z, visit >>> http://wiki.linuxvm.org/ >>> >> >> ---------------------------------------------------------------------- >> For LINUX-390 subscribe / signoff / archive access instructions, >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 >> or visit >> http://www.marist.edu/htbin/wlvindex?LINUX-390 >> ---------------------------------------------------------------------- >> For more information on Linux on System z, visit >> http://wiki.linuxvm.org/ >> > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
