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 <[email protected]>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 <[email protected]> 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 < >> [email protected]> 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" <[email protected]> >>> 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 : [email protected] >>>> 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 : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > > -- Andrey Danin [email protected] skype: gcon.monolake
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
