fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

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