Max, can you create a blueprint for this? Or you need our help to do that?
On Mon, Mar 31, 2014 at 9:27 AM, Mike Scherbakov <[email protected]>wrote: > > Will it be a default disk allocation which a user can change via UI > yes. > > > We can do disks_for_mongo = floor (free_disks * mongo_compute_coeff) > and take mongo_compute_coeff from openstack.yaml > this is good idea indeed. > > > On Thu, Mar 27, 2014 at 7:26 PM, Andrey Danin <[email protected]> wrote: > >> I agree with your suggestion. Will it be a default disk allocation which >> a user can change via UI? If so, it seems a good solution for now. >> We can do disks_for_mongo = floor (free_disks * mongo_compute_coeff) and >> take mongo_compute_coeff from openstack.yaml >> >> >> On Thu, Mar 27, 2014 at 6:33 PM, Mike Scherbakov < >> [email protected]> wrote: >> >>> Sorry, >>> I meant disks_for_mongo = floor (free_disks / 2) >>> >>> >>> On Thu, Mar 27, 2014 at 6:19 PM, Andrey Danin <[email protected]>wrote: >>> >>>> What does floor() do? The free_disks variable is an integer and we >>>> cannot round it again. >>>> >>>> >>>> On Thu, Mar 27, 2014 at 4:47 PM, Mike Scherbakov < >>>> [email protected]> wrote: >>>> >>>>> My suggestion would be the following for now (let's improve when we >>>>> get more results): >>>>> >>>>> 1. For separated mongodb node >>>>> 1. If there are > 1 disk >>>>> 1. use 1 disk for os, all other disks for mongodb >>>>> 2. if 1 disk >>>>> 1. Use default os calculator, leave rest of the space for >>>>> mongodb >>>>> 2. For combination of mongodb with compute >>>>> 1. free_disks = disks - 1 (1 is for os); disks_for_mongo = >>>>> floor (free_disks), rest for virtual storage, and first disk for >>>>> both os & >>>>> virtual storage >>>>> >>>>> So idea is to allocate separated disks for mongodb where possible. At >>>>> the same time, still leaving space for virtual storage and other roles. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> On Wed, Mar 26, 2014 at 6:59 PM, Maksim Mazur <[email protected]>wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> >>disk allocation scheme should be researched by the team >>>>>> implementing the feature. In this case, hardware requirements information >>>>>> and disk allocation scheme draft should be written down into the >>>>>> blueprint. >>>>>> Only after this is done, we can start discussing the particular >>>>>> implementation. >>>>>> >>>>>> As far as I know "team" implementing this feature is the only one >>>>>> person. And I don not have hardware to make performance tests right now. >>>>>> And I'm little bit overloaded on Mirantis OpenStack Express project. >>>>>> >>>>>> As temporary solution I can propose the following solution. >>>>>> >>>>>> 1. For now we leave disk allocation as is. >>>>>> 2. On MOE we have hardware to test so if Ceilometer will be included >>>>>> in next release we will be able to do full testing in real hardware up to >>>>>> 20 hardware nodes. >>>>>> 3. After tests I will be able to give any recommendations about disks >>>>>> allocation. >>>>>> >>>>>> >>>>>> Otherwise I need help to do testing and create design documents. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 26, 2014 at 4:08 PM, Mike Scherbakov < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Why can't we track storage for mongo as just one of the tasks in >>>>>>> existing blueprint for ceilometer-mongodb? It looks to me pretty >>>>>>> granular >>>>>>> one. More over, I think we need to keep such details in one single >>>>>>> design >>>>>>> document of the bigger story. >>>>>>> >>>>>>> There was a document with numbers regarding disk consumption, not >>>>>>> sure about IO. Max, do you have this info? Based on disk IO & space >>>>>>> requirements we are all can propose and come to an agreement in logic >>>>>>> for >>>>>>> disk partitioning. For example, if IO is high, we may always require >>>>>>> separated disk(s) for it. There is might be recommendation on fs type >>>>>>> for >>>>>>> mongodb as well. We mongodb is collacated with some other roles, such as >>>>>>> compute, we will need to come up with logic how to distribute disk space >>>>>>> between "virtual storage" LVM and mongodb (50/50 or other ratio?). >>>>>>> >>>>>> As far as I know data amount in ceilometer DB depends on number of >>>>>> VMs on stack so it is impossible to predict how much space will we need. >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> On Mar 26, 2014 5:43 PM, "Bogdan Dobrelya" <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On 03/26/2014 02:15 PM, Maksim Mazur wrote: >>>>>>>> > Hi! >>>>>>>> > >>>>>>>> > I need to create disk allocation rule for MongoDB role. (MongoDB >>>>>>>> is >>>>>>>> > NoSQL backend for Ceilometer) >>>>>>>> > >>>>>>>> > >>>>>>>> > I have no experience with high-loaded MongoDB single instances or >>>>>>>> > ReplicaSets. >>>>>>>> > >>>>>>>> > For the first view having a dedicated drive or raid array for >>>>>>>> MondoDB >>>>>>>> > data looks like good idea for large installations but it is >>>>>>>> overkill for >>>>>>>> > small stacks. >>>>>>>> > And I'm not sure is it possible to use dedicated drive if MongoDB >>>>>>>> role >>>>>>>> > applyed on Controller. >>>>>>>> > >>>>>>>> > >>>>>>>> > Could you please help me with task? >>>>>>>> > >>>>>>>> > >>>>>>>> > Best Regards, >>>>>>>> > Max Mazur. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> Hi all. >>>>>>>> >>>>>>>> I suggest to follow the existing guideline Fuel UI provides for >>>>>>>> disks >>>>>>>> configuration for nodes. As a start, you could create a new >>>>>>>> blueprint to >>>>>>>> define new storage ("Mongo DB Storage") for Nailgun UI to be used by >>>>>>>> Fuel on provision stage. >>>>>>>> >>>>>>>> There are a similar tasks with "Openstack DB Storage" (in TODO >>>>>>>> list) and >>>>>>>> separated "Logs Storage" ( see >>>>>>>> >>>>>>>> https://etherpad.openstack.org/p/manage-logs-with-free-space-consideration >>>>>>>> for BP >>>>>>>> >>>>>>>> https://blueprints.launchpad.net/fuel/+spec/manage-logs-with-free-space-consideration >>>>>>>> ) >>>>>>>> >>>>>>>> Note: the blueprint was not approved yet, but I believe some >>>>>>>> patterns >>>>>>>> could be reused for Mongo/Openstack DB storages as well... E.g. the >>>>>>>> sections 'Fuel-UI requirements', 'Planning disk partitions, RAID >>>>>>>> type, >>>>>>>> logical volume for Remote Logs Storage'. >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Bogdan Dobrelya, >>>>>>>> Skype #bogdando_at_yahoo.com >>>>>>>> Irc #bogdando >>>>>>>> >>>>>>>> -- >>>>>>>> Mailing list: https://launchpad.net/~fuel-dev >>>>>>>> Post to : [email protected] >>>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>> >>>>>> >>>>>> Best Regards, >>>>>> Max Mazur >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mike Scherbakov >>>>> #mihgen >>>>> >>>>> -- >>>>> Mailing list: https://launchpad.net/~fuel-dev >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> >>>> -- >>>> Andrey Danin >>>> [email protected] >>>> skype: gcon.monolake >>>> >>> >>> >>> >>> -- >>> Mike Scherbakov >>> #mihgen >>> >> >> >> >> -- >> Andrey Danin >> [email protected] >> skype: gcon.monolake >> > > > > -- > Mike Scherbakov > #mihgen > -- Andrey Danin [email protected] skype: gcon.monolake
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
