On Friday, July 5, 2019 11:50:44 AM CDT Paul Emmerich wrote:
> * There are virtually no use cases for ec pools with m=1, this is a bad
> configuration as you can't have both availability and durability
I'll have to look into this more. The cluster only has 4 hosts, so it might be
worth switching
On Friday, July 5, 2019 11:28:32 AM CDT Caspar Smit wrote:
> Kyle,
>
> Was the cluster still backfilling when you removed osd 6 or did you only
> check its utilization?
Yes, still backfilling.
>
> Running an EC pool with m=1 is a bad idea. EC pool min_size = k+1 so los
hey shouldn't suffer data loss with a single
osd being removed even if there were no reweighting beforehand. Does the
backfilling temporarily reduce data durability in some way?
Is there a way to see which pgs actually have data on a given osd?
I attached an example of one of
h for the information. Once I have a little more, I'm
probably going to work towards sending a pull request in for the docs...
--Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
a critique of this setup / a better way of
organizing this, suggestions are welcome.
Thanks,
--Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
f I
can get any more info as to why this is happening?
On Thu, Feb 8, 2018 at 3:02 AM, Mike O'Connor wrote:
> On 7/02/2018 8:23 AM, Kyle Hutson wrote:
> > We had a 26-node production ceph cluster which we upgraded to Luminous
> > a little over a month ago. I added a 27th-n
We had a 26-node production ceph cluster which we upgraded to Luminous a
little over a month ago. I added a 27th-node with Bluestore and didn't have
any issues, so I began converting the others, one at a time. The first two
went off pretty smoothly, but the 3rd is doing something strange.
Initiall
Sun, Apr 9, 2017 at 11:41 AM, Kyle Drake wrote:
> On Sun, Apr 9, 2017 at 9:31 AM, John Spray wrote:
>
>> On Sun, Apr 9, 2017 at 12:48 AM, Kyle Drake wrote:
>> > Pretty much says it all. 1GB test file copy to local:
>> >
>> > $ time cp /mnt/ceph-kerne
On Sun, Apr 9, 2017 at 9:31 AM, John Spray wrote:
> On Sun, Apr 9, 2017 at 12:48 AM, Kyle Drake wrote:
> > Pretty much says it all. 1GB test file copy to local:
> >
> > $ time cp /mnt/ceph-kernel-driver-test/test.img .
> >
> > real 2m50.063s
> > user 0m0.
Pretty much says it all. 1GB test file copy to local:
$ time cp /mnt/ceph-kernel-driver-test/test.img .
real 2m50.063s
user 0m0.000s
sys 0m9.000s
$ time cp /mnt/ceph-fuse-test/test.img .
real 0m3.648s
user 0m0.000s
sys 0m1.872s
Yikes. The kernel driver averages ~5MB and the fuse driver average
Burkhard Linke writes:
>
> The default weight is the size of the OSD in tera bytes. Did you
use
> a very small OSD partition for test purposes, e.g. 20 GB? In that
> case the weight is rounded and results in an effective weight of
> 0.0. As a result the OSD will not be used
Hello,
I have been working on a very basic cluster with 3 nodes and a single OSD
per node. I am using Hammer installed on CentOS 7
(ceph-0.94.5-0.el7.x86_64) since it is the LTS version. I kept running
into an issue of not getting past the status of
undersized+degraded+peered. I finally discove
Nice! Thanks!
On Wed, Oct 14, 2015 at 1:23 PM, Sage Weil wrote:
> On Wed, 14 Oct 2015, Kyle Hutson wrote:
> > > Which bug? We want to fix hammer, too!
> >
> > This
> > one:
> https://www.mail-archive.com/ceph-users@lists.ceph.com/msg23915.html
> >
&
> Which bug? We want to fix hammer, too!
This one:
https://www.mail-archive.com/ceph-users@lists.ceph.com/msg23915.html
(Adam sits about 5' from me.)
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ce
A couple of questions related to this, especially since we have a hammer
bug that's biting us so we're anxious to upgrade to Infernalis.
1) RE: ibrbd and librados ABI compatibility is broken. Be careful installing
this RC on client machines (e.g., those running qemu). It will be fixed in
the fina
for a read-cache. Is
that something that's being done, can be done, is going to be done, or has
even been considered?
On Wed, Sep 9, 2015 at 10:33 AM, Gregory Farnum wrote:
> On Wed, Sep 9, 2015 at 4:26 PM, Kyle Hutson wrote:
> >
> >
> > On Wed, Sep 9, 2015 at 9:34 AM, G
On Wed, Sep 9, 2015 at 9:34 AM, Gregory Farnum wrote:
> On Wed, Sep 9, 2015 at 3:27 PM, Kyle Hutson wrote:
> > We are using Hammer - latest released version. How do I check if it's
> > getting promoted into the cache?
>
> Umm...that's a good question. You can
We are using Hammer - latest released version. How do I check if it's
getting promoted into the cache?
We're using the latest ceph kernel client. Where do I poke at readahead
settings there?
On Tue, Sep 8, 2015 at 8:29 AM, Gregory Farnum wrote:
> On Thu, Sep 3, 2015 at 11:58 PM
I was wondering if anybody could give me some insight as to how CephFS does
its caching - read-caching in particular.
We are using CephFS with an EC pool on the backend with a replicated cache
pool in front of it. We're seeing some very slow read times. Trying to
compute an md5sum on a 15GB file t
from our data center to
> our AWS cluster allowing us to "migrate" to AWS.
This sounds far more sensible. I'd look at the I2 (iops) or D2
(density) class instances, depending on use case.
--
Kyle
___
ceph-users mailing list
ceph-users@l
Thank you, John!
That was exactly the bug we were hitting. My Google-fu didn't lead me to
this one.
On Wed, Apr 15, 2015 at 4:16 PM, John Spray wrote:
> On 15/04/2015 20:02, Kyle Hutson wrote:
>
>> I upgraded to 0.94.1 from 0.94 on Monday, and everything had been goi
I upgraded to 0.94.1 from 0.94 on Monday, and everything had been going
pretty well.
Then, about noon today, we had an mds crash. And then the failover mds
crashed. And this cascaded through all 4 mds servers we have.
If I try to start it ('service ceph start mds' on CentOS 7.1), it appears
to be
at we can inspect it with our tools?
> -Greg
>
> On Thu, Apr 9, 2015 at 7:57 AM, Kyle Hutson wrote:
> > Here 'tis:
> > https://dpaste.de/POr1
> >
> >
> > On Thu, Apr 9, 2015 at 9:49 AM, Gregory Farnum wrote:
> >>
> >> Can you dump your
Here 'tis:
https://dpaste.de/POr1
On Thu, Apr 9, 2015 at 9:49 AM, Gregory Farnum wrote:
> Can you dump your crush map and post it on pastebin or something?
>
> On Thu, Apr 9, 2015 at 7:26 AM, Kyle Hutson wrote:
> > Nope - it's 64-bit.
> >
> > (So
x27;s the only thing i can
> think of that might have slipped through our QA.)
>
> On Thu, Apr 9, 2015 at 7:17 AM, Kyle Hutson wrote:
> > I did nothing to enable anything else. Just changed my ceph repo from
> > 'giant' to 'hammer', then did 'yum upd
2aca <
server's 102b84a042aca, missing 1
It appears that even the latest kernel doesn't have support
for CEPH_FEATURE_CRUSH_V4
How do I make my ceph cluster backward-compatible with the old cephfs
client?
On Thu, Apr 9, 2015 at 8:58 AM, Kyle Hutson wrote:
> I upgraded from gi
I upgraded from giant to hammer yesterday and now 'ceph -w' is constantly
repeating this message:
2015-04-09 08:50:26.318042 7f95dbf86700 0 -- 10.5.38.1:0/2037478 >>
10.5.38.1:6789/0 pipe(0x7f95e00256e0 sd=3 :39489 s=1 pgs=0 cs=0 l=1
c=0x7f95e0023670).connect protocol feature mismatch, my 3ff
For what it's worth, I don't think "being patient" was the answer. I was
having the same problem a couple of weeks ago, and I waited from before 5pm
one day until after 8am the next, and still got the same errors. I ended up
adding a "new" cephfs pool with a newly-created small pool, but was never
zation issue, I believe.
>
>
>
> -don-
>
>
>
> *From:* ceph-users [mailto:ceph-users-boun...@lists.ceph.com] *On Behalf
> Of *Don Doerner
> *Sent:* 04 March, 2015 12:49
> *To:* Kyle Hutson
> *Cc:* ceph-users@lists.ceph.com
>
> *Subject:* Re: [ceph-users] New
That did it.
'step set_choose_tries 200' fixed the problem right away.
Thanks Yann!
On Wed, Mar 4, 2015 at 2:59 PM, Yann Dupont wrote:
>
> Le 04/03/2015 21:48, Don Doerner a écrit :
>
> Hmmm, I just struggled through this myself. How many racks do you have?
> If not more than 8, you might w
Hmmm, I just struggled through this myself. How many racks do you have?
> If not more than 8, you might want to make your failure domain smaller? I.e.,
> maybe host? That, at least, would allow you to debug the situation…
>
>
>
> -don-
>
>
>
> *From:* Kyle Hutson [m
Don Doerner wrote:
> Oh duh… OK, then given a 4+4 erasure coding scheme, 14400/8 is 1800, so
> try 2048.
>
>
>
> -don-
>
>
>
> *From:* ceph-users [mailto:ceph-users-boun...@lists.ceph.com] *On Behalf
> Of *Don Doerner
> *Sent:* 04 March, 2015 12:14
> *To:* Kyle H
Last night I blew away my previous ceph configuration (this environment is
pre-production) and have 0.87.1 installed. I've manually edited the
crushmap so it down looks like https://dpaste.de/OLEa
I currently have 144 OSDs on 8 nodes.
After increasing pg_num and pgp_num to a more suitable 1024 (d
Just did it. Thanks for suggesting it.
On Wed, Feb 25, 2015 at 5:59 PM, Brad Hubbard wrote:
> On 02/26/2015 09:05 AM, Kyle Hutson wrote:
>
>> Thank you Thomas. You at least made me look it the right spot. Their
>> long-form is showing what to do for a mon, not an osd.
>
osd_host to just host. See if that works.
> On Feb 25, 2015 5:44 PM, "Kyle Hutson" wrote:
>
>> I just tried it, and that does indeed get the OSD to start.
>>
>> However, it doesn't add it to the appropriate place so it would survive a
>> reboot. In m
7;t start the long
> running process.
>
> On Wed, Feb 25, 2015 at 2:59 PM, Kyle Hutson wrote:
> > But I already issued that command (back in step 6).
> >
> > The interesting part is that "ceph-disk activate" apparently does it
> > correctly. Even after reb
n't start the long
> running process.
>
> On Wed, Feb 25, 2015 at 2:59 PM, Kyle Hutson wrote:
> > But I already issued that command (back in step 6).
> >
> > The interesting part is that "ceph-disk activate" apparently does it
> > correctly. Even after
st root=default). To restart an OSD
> process, I just kill the PID for the OSD then issue ceph-disk activate
> /dev/sdx1 to restart the OSD process. You probably could stop it with
> systemctl since I believe udev creates a resource for it (I should
> probably look into that now that t
I'm having a similar issue.
I'm following http://ceph.com/docs/master/install/manual-deployment/ to a T.
I have OSDs on the same host deployed with the short-form and they work
fine. I am trying to deploy some more via the long form (because I want
them to appear in a different location in the cr
Oh, and I don't yet have any important data here, so I'm not worried about
losing anything at this point. I just need to get my cluster happy again so
I can play with it some more.
On Fri, Feb 20, 2015 at 11:00 AM, Kyle Hutson wrote:
> Here was the process I went through.
> 1)
; http://ceph.com/docs/giant/dev/erasure-coded-pool/ to create the EC pool.
>
> I'm not sure (i.e. I never tried) to create a EC pool the way you did. The
> normal replicated ones do work like this.
>
> On Fri, Feb 20, 2015 at 4:49 PM, Kyle Hutson wrote:
>
>> I manual
I manually edited my crushmap, basing my changes on
http://www.sebastien-han.fr/blog/2014/08/25/ceph-mix-sata-and-ssd-within-the-same-box/
I have SSDs and HDDs in the same box and was wanting to separate them by
ruleset. My current crushmap can be seen at http://pastie.org/9966238
I had it install
> do people consider a UPS + Shutdown procedures a suitable substitute?
I certainly wouldn't, I've seen utility power fail and the transfer
switch fail to transition to UPS strings. Had this happened to me with
nobarrier it would have been a very sad day.
--
e a short io stall. The more careful approach would be to 'ceph
osd set noup' mark all the osds on a node down, move the link, 'ceph
osd unset noup', and then wait for their peers to mark them back up
before proceeding to the next host.
--
Kyle
_
d be relatively straight forward. Simply configure the
VLAN/subnets on the new physical switches and move links over one by
one. Once all the links are moved over you can remove the VLAN and
subnets that are now on the new kit from the original hardw
> Can you paste me the whole output of the install? I am curious why/how you
> are getting el7 and el6 packages.
priority=1 required in /etc/yum.repos.d/ceph.repo entries
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.co
xattrs - xfs by default. As such you can use kernel
instrumentation to view what is going on "under" the Ceph OSDs.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
kups on
an erasure coded pool, I'm not sure if that has been tested, but in
principle should work since objects composing a snapshot should be
immutable.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
year. Even a datacenter with five nines power availability is going to
see > 5m of downtime per year, and that would qualify for the highest
rating from the Uptime Institute (Tier IV)! I've lost power to Ceph
clusters on several occasions, in all cases the journals were on
spinn
> Anyway replacing set of monitors means downtime for every client, so
> I`m in doubt if 'no outage' word is still applicable there.
Taking the entire quorum down for migration would be bad. It's better
to add one in the new location, remove one at the old, ad
a then it may take a long time or be disruptive, make sure you've
tested that your recovery tunables are suitable for your hardware
configuration.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
g of
> objects (so as to get more aggregate read cache). I assume the standard
> wisdom with write-back cache-tiering is that the backing data pool shouldn't
> bother with ssd journals?
Currently, all cache tiers need to be durable - regardless of cache
mode. As such, cache tiers should
ews. If you want host independence, durability and speed your
best bet is a replicated cache pool (2-3x).
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Ceph storage back to the
> pool?
VMs running a 3.2+ kernel (iirc) can "give back blocks" by issuing TRIM.
http://wiki.qemu.org/Features/QED/Trim
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> I have run the repair command, and the warning info disappears in the
output of "ceph health detail", but the replicas isn't recovered in the
"current" directory.
> In all, the ceph cluster status can recover (the pg's status recover from
inconsistent to active and clean), but not the replica.
I
ou really need to have monitors on 3 distinct physical hosts to
protect against the failure of a physical host.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
rubbing the placement group
containing the removed object and let us know if it triggers recovery?
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
/x ];do sleep 1; done''
run: '/usr/sbin/ceph-disk-activate /dev/mapper/x'
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
en no data will be moved to the OSD when it joins the
cluster. Only once the weight has been increased with the rest of the
OSD population will data start to move to the new OSD(s). If you add
new OSD(s) with an initial weight > 0 then they will start accepting
data from peers as soon
loser to what the tiering feature will offer, except the
flashcache OSD method is more particular about disk:ssd ratio, whereas
in a tier the flash could be on s completely separate hosts (possibly
dedicated flash machines).
--
Kyle
___
ceph-users
volume (defaults to formatting xfs). This is known as a single device
OSD, in contrast with a multi-device OSD where the journal is on a
completely different device (like a partition on a shared journaling
SSD).
--
Kyle
___
ceph-users mailing list
ceph
> We use /dev/disk/by-path for this reason, but we confirmed that is stable
> for our HBAs. Maybe /dev/disk/by-something is consistent with your
> controller.
The upstart/udev scripts will handle mounting and osd id detection, at
least on Ubuntu.
ing a smaller WAN MTU?
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> You're right. Sorry didn't specify I was trying this for Radosgw. Even for
> this I'm seeing performance degrade once my clients start to hit the LB VIP.
Could you tell us more about your load balancer and configuration?
--
Kyle
_
irtual Server or
HAProxy/Nginx. The other components of Ceph are horizontally scalable
and because of the way Ceph's native protocols work you don't need
load balancers doing L2/L3/L7 tricks to achieve HA.
--
Kyle
___
ceph-users mailing
nce the rbd engine is new:
https://github.com/axboe/fio
Assuming you already have a cluster and a client configured this
should do the trick:
https://github.com/axboe/fio/blob/master/examples/rbd.fio
--
Kyle
___
ceph-users mailing list
ceph-
tem overhead
Nope!
> Any other feedback regarding our plan would also be welcomed.
I would probably run each disk as it's own OSD, which means you need a
bit more memory per host. Networking could certainly be a bottleneck
with 8 to 16 spindle nodes. YMMV.
--
Kyle
s to storage media. With a
different key per VM, with potentially millions of tenants, you now
have a massive key escrow/management problem that only buys you a bit
of additional security when block devices are detached. Sounds like a
crappy deal to me, I'd either go with #1 or #3.
--
Kyle
> Why the limit of 6 OSDs per SSD?
SATA/SAS throughput generally.
> I am doing testing with a PCI-e based SSD, and showing that even with 15
OSD disk drives per SSD that the SSD is keeping up.
That will probably be fine performance wise but it's worth noting that all
OSDs will fail if the flash
ld access). This means #2 is safe so long as you never mount
the volume, which means it's utility is rather limited (archive
perhaps). Neither of these schemes buy you much more than the
encryption handling provided by ceph-disk-prepare (dmcrypted osd
data/journal volumes
> Is there an issue with IO performance?
Ceph monitors store cluster maps and various other things in leveldb,
which persists to disk. I wouldn't recommend using a sd/usb cards for
the monitor store because they tend to be slow and have poor
durability.
-
read datas on DC1 ?
No yet!
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> Why would it help? Since it's not that ONE OSD will be primary for all
objects. There will be 1 Primary OSD per PG and you'll probably have a
couple of thousands PGs.
The primary may be across a oversubscribed/expensive link, in which case a
local replica with a common ancestor to the client may
> Change pg_num for .rgw.buckets to power of 2, an 'crush tunables
> optimal' didn't help :(
Did you bump pgp_num as well? The split pgs will stay in place until
pgp_num is bumped as well, if you do this be prepared for (potentially
lots) of data movement.
_
> HEALTH_WARN 1 pgs down; 3 pgs incomplete; 3 pgs stuck inactive; 3 pgs
stuck unclean; 7 requests are blocked > 32 sec; 3 osds have slow requests;
pool cloudstack has too few pgs; pool .rgw.buckets has too few pgs
> pg 14.0 is stuck inactive since forever, current state incomplete, last
acting [5,0
gt; wants to use Ceph for VM storage in the future, we need to find a solution.
That's a shame, but at least you will be better prepared if it happens
again, hopefully your luck is not as unfortunate as mine!
--
Kyle Bader
___
ceph-users mailin
e their traffic over the public network if that
> was still available in case the cluster network fails?
Ceph doesn't currently support this type of configuration.
Hope that clears things up!
--
Kyle
___
ceph-users mailing list
ceph-us
t Size: 4MB
It seems that the number of disks is not considered when calculating
the recovery window, only the number of pgs
https://github.com/ceph/ceph-tools/blob/master/models/reliability/RadosRely.py#L68
I could also see the recovery rates varying based on the max osd
backfill tunable.
htt
; declustering:1100 PG/OSD
>> NRE model: fail
>> object size: 4MB
>> stripe length: 1100
> I take it that is to mean that any RBD volume of sufficient size is indeed
> spread over all disks?
Spread over all placement groups, the differe
+03
[1] https://github.com/ceph/ceph-tools/tree/master/models/reliability
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
number of nodes you have/plan to
have you will be utilizing 6-12 links per switch, leaving you with 12-18
links for clients on a non-blocking fabric, 24-30 for 2:1 and 36-48 for 4:1.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> Do you have any futher detail on this radosgw bug?
https://github.com/ceph/ceph/commit/0f36eddbe7e745665a634a16bf3bf35a3d0ac424
https://github.com/ceph/ceph/commit/0b9dc0e5890237368ba3dc34cb029010cb0b67fd
> Does it only apply to emperor?
The bug is present in dumpling too.
>> Has anyone tried scaling a VMs io by adding additional disks and
>> striping them in the guest os? I am curious what effect this would have
>> on io performance?
> Why would it? You can also change the stripe size of the RBD image.
Depending on the workload you might change it from 4MB to some
For you holiday pleasure I've prepared a SysAdvent article on Ceph:
http://sysadvent.blogspot.com/2013/12/day-15-distributed-storage-with-ceph.html
Check it out!
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.cep
as a drop in replacement that
provides a Swift compatible endpoint. Alternatively, the docs for
using Hadoop in conjunction with CephFS are here:
http://ceph.com/docs/master/cephfs/hadoop/
Hopefully that puts you in the right direction!
--
Kyle
___
ceph-us
h and
the upstart scripts.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> I've been running similar calculations recently. I've been using this
> tool from Inktank to calculate RADOS reliabilities with different
> assumptions:
> https://github.com/ceph/ceph-tools/tree/master/models/reliability
>
> But I've also had similar questions about RBD (or any multi-part files
enstack-cloud-software/technology/#storage
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
the cluster network, we
configured each to use mode 802.3ad.
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
ld very well end up being a limiting
> factor.
Sorry I read Mbytes and Mbps, big difference, the former is much preferable!
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> Is having two cluster networks like this a supported configuration? Every
osd and mon can reach every other so I think it should be.
Maybe. If your back end network is a supernet and each cluster network is a
subnet of that supernet. For example:
Ceph.conf cluster network (supernet): 10.0.0.0/8
> This journal problem is a bit of wizardry to me, I even had weird
intermittent issues with OSDs not starting because the journal was not
found, so please do not hesitate to suggest a better journal setup.
You mentioned using SAS for journal, if your OSDs are SATA and a expander
is in the data pa
> > Is the OS doing anything apart from ceph? Would booting a ramdisk-only
system from USB or compact flash work?
I haven't tested this kind of configuration myself but I can't think of
anything that would preclude this type of setup. I'd probably use sqashfs
layered with a tmpfs via aufs to avoid
evalent as RBD
via Qemu/KVM. This might be a starting point if your interested in
testing Xen/RBD integration:
http://wiki.xenproject.org/wiki/Ceph_and_libvirt_technology_preview
Hope that helps!
--
Kyle
___
ceph-users mailing list
ceph-users@lists
to the ceph package don't replace the files, maybe
that means making a null rule and using "-o
Dpkg::Options::='--force-confold" in ceph-deploy/chef/puppet/whatever.
You will also want to avoid putting the mounts in fstab because it
could render your node unbootable
;t produce a lot of writes then having it on the main disk
> should work okay. I've done it exactly as you describe before.
>
> James
>
> ___
> ceph-users mailing list
> ceph-users@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
onded 1GbE links for the cluster
network. The issues we've seen with 1GbE are complexity, shallow
buffers on 1GbE top of rack switch gear (Cisco 4948-10G) and the fact
that not all flows are equal (4x 1GbE != 4GbE).
--
Kyle
___
ceph-users mailing li
cebook/flashcache/
http://bcache.evilpiepirate.org/
If you have any questions let us know!
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> 3).Comment out, #hashtag the bad OSD drives in the “/etc/fstab”.
This is unnecessary if your using the provided upstart and udev
scripts, OSD data devices will be identified by label and mounted. If
you choose not to use the upstart and udev scripts then you should
write init scripts that do si
> Would this be something like
> http://wiki.ceph.com/01Planning/02Blueprints/Firefly/Ceph-Brag ?
Something very much like that :)
--
Kyle
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
1 - 100 of 124 matches
Mail list logo
