fuel-dev team mailing list archive

[Andrey Danin <adanin@xxxxxxxxxxxx>]

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
<mscherbakov@xxxxxxxxxxxx>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 <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
>



-- 
Andrey Danin
adanin@xxxxxxxxxxxx
skype: gcon.monolake