Ilya that is interesting. By multiple CloudStack environments, you mean environments that do not have any link between them? I mean, they are not “regions” of one another or something like that.
Do you intend to manage configurations such as over-provisioning factors, allocation threshold, Wait timeouts and others? What else do you look forward to manage? I understand the point that now your employer may not want to open it; but, maybe in the future ;) We have some other questions here: For instance, the balancing of VMs workloads in the cloud environment; of course, one can extend the CloudStack allocation algorithms and try to place VMs in a balancing manner. However, that would just be based on the resource allocation. I believe that the balancing/dispersion of VMs should also consider the resource usage. The problem is that Cloud computing is a rather dynamic environment; workloads can change their pattern of resource usage all the time. Therefore, executing the VMs balancing only at the deploy time would not be the best option. Maybe some agents that work autonomously managing the environment would be a better approach. We also have the size of such environments as a huge challenge; the agent would no be able to gather information, analyse it and then act upon the environment at once. It would be better to act upon pieces of the environment at time Another example is the number of idle hosts in cloud environments. Giving the dynamic nature of the cloud, sometimes the load is pretty high while other times it is pretty low. For example, in my environment (right now) the allocation ratio of memory is 91% and CPU 94%. However, there are at least 5-6 months a year that we have ratios below 60%. That means that we have idle servers wasting energy and cooling. Again we have the same problem, a dynamic environment in which we never know for sure when a load is coming. For this solution, an agent that constantly acts on the environment would be interesting. This agent could detect unused servers and power them off; then, if a shortage of resource happens, we could start deactivated servers. This way we could save some great deal of energy. Has anyone of you here thought/dealt with such situations? Do you care about such problems? On Tue, Apr 12, 2016 at 1:18 PM, ilya <ilya.mailing.li...@gmail.com> wrote: > I started working on another project that will consolidate multiple > cloudstack into "1" to manage and check the health of the dispersed > cloudstack environments. Conceptually, anything i do through "CloudStack > Manager" would be replayed down to all other dispersed cloudstacks > across the globe. > > It would be relatively easy to write "CloudStack Manager" since > cloudstack is API driven via Rest-like interface. > > Unfortunately, i don't believe my employer would let me open source this > project, though i will try. > > > > On 4/11/16 8:44 AM, Gabriel Beims Bräscher wrote: > > Dear Apache CloudStack users, > > > > I have been discussing with some colleagues about solutions that can help > > us to manage our Apache CloudStack (ACS) environments. By management I > > mean, dealing with service level agreements (SLAs), management of idle > > hosts, the balancing of the environment's virtual machine loads, and the > > monitoring and tracking of resource usage (not only allocation). > > > > Have you guys dealt with those situations and any other that you would > > consider as a day-to-day management situation? How did you work them out? > > > > It would be helpful to hear back your thoughts. > > > > Thanks for your time, > > Gabriel. > > > -- Rafael Weingärtner
