fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

> 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 <adanin@xxxxxxxxxxxx> 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 <mscherbakov@xxxxxxxxxxxx
> > wrote:
>
>> Sorry,
>> I meant disks_for_mongo = floor (free_disks / 2)
>>
>>
>> On Thu, Mar 27, 2014 at 6:19 PM, Andrey Danin <adanin@xxxxxxxxxxxx>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 <
>>> mscherbakov@xxxxxxxxxxxx> 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 <mmaxur@xxxxxxxxxxxx>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 <
>>>>> mscherbakov@xxxxxxxxxxxx> 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" <bdobrelia@xxxxxxxxxxxx>
>>>>>> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>>>> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrey Danin
>>> adanin@xxxxxxxxxxxx
>>> skype: gcon.monolake
>>>
>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>
>
>
> --
> Andrey Danin
> adanin@xxxxxxxxxxxx
> skype: gcon.monolake
>



-- 
Mike Scherbakov
#mihgen