sgs-ceph-pools
Creating ceph pools
SGS requires four ceph pools. Although
these can be the same pool with no problems,
having them as different pools will allow you to migrate
onto different storage later without any difficulty.
The first two pools are the ones that
BTrDB uses to store data. The pools can have any
names, you will specify the pool names in the site config in the
next step. If you have a fair bit of SSD storage in your cluster
it is recommended to place the btrdb_hot
pool on
SSD.
ceph osd pool create btrdb_hot 256 256
ceph osd pool create btrdb_data 256 256
The next pool is for the BTrDB journal. This SHOULD be on SSD, but it won't ever grow particularly big. A pool of about 100GB should suffice even in production. You can put this on spinning metal, but not in production.
ceph osd pool create btrdb_journal 256 256
The final pool is used by the receiver/ingester
daemon pair for storing incoming PMU data in its raw form before
it is processed by BTrDB. This stage is skipped if you use the pmu2btrdb
ingress daemon.
ceph osd pool create staging 256 256
For details on the ceph osd pool
command, such as how to specify the placement ruleset, consult the
ceph documentation.
In particular, a placement group count of 256 is appropriate for
between 5 and 10 OSDs assuming you are creating four
pools.
Exactly
I mean really
We are in particular interested in
* rapid prototyping of new building systems,* analysis of the operation of existing building systems,* development, specification, verification and deployment of building controls within a model-based design process,* reuse of models during operation for functional testing, for verification of control sequences, for energy-minimizing controls, fault detection and diagnostics,* active involvement of the simulation users in the development process to ensure that users' needs are met, and* providing to users an open-source library of building, HVAC and controls components and systems that they can use, extend and adjust to suit their needs.