@Ivan, I'm assunibng Yiping meant other users of CLoudStack (not users inside CLoudStack) - so yes for us admins...
So we are talking about deployment planner - in similar way as we have couple of them for the VM deployment (UserDispersing, UserConcetrated, etc) I like the idea in general. On Fri, 16 Nov 2018 at 20:29, Yiping Zhang <[email protected]> wrote: > Hi, Ivan: > > I think one or more deployment planner for storage to handle automatic > storage placement for new images is a good idea (when multiple primary > storages are available). But on top of that, letting admins to manually > pick storage device (to override deployment planner selection) is also a > good thing to have, giving that it is simply not possible for any > deployment planner to handle all possible situations out there. > > Yiping > > On 11/16/18, 10:49 AM, "Ivan Kudryavtsev" <[email protected]> > wrote: > > Hi, Yiping. This is important feature especially for those, who use > local > storage deployments. > > But I don't think regular users must be able doing that. Admins may > have > that feature, but users must perceipt the cloud as incapsulated service > with hidden topology. What they need is a deployment planner for a > storage. > > The request itself is useful, but the feature design must fit every > kind of > cloud use case, not only yours. > > > пт, 16 нояб. 2018 г., 13:10 Yiping Zhang [email protected]: > > > It sounds like we have an enhancement/feature request here: to be > able to > > specify primary storage device where the new image to be created on > when > > calling deployVirtualMachine API. > > > > Where should I file this request, in Github or the original Apache's > > CloudStack Jira? > > > > Yiping > > > > On 11/15/18, 2:27 PM, "Andrija Panic" <[email protected]> > wrote: > > > > I believe (if not mistaken) that CloudStack will match first > available > > storage based on storage tags and availability, and will always > choose > > first storage pool, even though you have 3 of them available for > > particular > > cluster. > > In this sense, you can not really balance load across multiple > Primary > > Storages... (I have actually just tested this, having 2 pools > with same > > storage tag, and deploying a few volumes - all of them were > created on > > first storage available...) > > > > You could configure them with different storage tags, but not > sure that > > solves your problem - i.e. some Compute/Disk offerings will be > > targeting > > NetApp Cluster1, some NetApp 2, some NetApp3 - but this is > impractical. > > > > Not sure if someone else can shred some light on this scenario ? > (I > > could > > atm imagine a very specific game with editing storage tags on > > storage_pool > > via SQL (scheduled job), in order to "rotate" list of available > storage > > pools...) > > > > Cheers > > > > On Thu, 15 Nov 2018 at 23:01, Yiping Zhang <[email protected]> > wrote: > > > > > Hi, all: > > > > > > At my site, our currently practice is to have only one primary > > storage > > > device for each CloudStack cluster, serving up to 500 disk > volumes > > with > > > total of 10 – 20TB disk space. Now, we are replacing old > NetApp > > clusters > > > with new ones and moving to SSD disks, so I need to recreate > all my > > > primary storage devices. > > > > > > I am thinking of configuring three primary storage volumes, > each > > served by > > > a different NetApp cluster, for each CloudStack cluster to > divide > > work > > > load on the NetApp end, and to provide some storage redundancy > in > > > CloudStack. > > > > > > My question is when creating new VM instances, how would I > > distribute new > > > disk volumes on to different primary storage devices evenly and > > > automatically? > > > > > > I am wondering how are other users configure their (NFS) > primary > > storage > > > devices? What are your best practices in this area? > > > > > > Thanks > > > > > > Yiping > > > > > > > > > -- > > > > Andrija Panić > > > > > > > > > -- Andrija Panić
