fuel-dev team mailing list archive

[Andrey Danin <adanin@xxxxxxxxxxxx>]

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