fuel-dev team mailing list archive

[Andrey Danin <adanin@xxxxxxxxxxxx>]

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