Hi Lindsay ,
ceph-mgr runs as root , same as my test user. Dont think its a permissions
issues. Another forum member just advised that zabbix_sender binary needs
to be available in the container, something which indeed is not available.
On Mon, 6 Jul 2020 at 23:05, Lindsay Mathieson
wrote:
> On
Hi Konstantin,
Indeed i think that is the problem. I've just checked again and did docker
exec -it bin/bash and couldnt find any zabbix_sender
binary in the container. I have little knowledge of containers but i guess
to change the container will be a pain as this is pretty closed system
which wa
On 7/6/20 7:54 PM, etiennem...@gmail.com wrote:
We are trying to make work the Zabbix module of our ceph cluster but im
encountering an issue that got me stuck.
Configuration of the module looks ok and we manage to send data using
zabbix_sender to the host that is configured on Zabbix. We can
Hi:
We have a cluster (v13.2.4), and we do some tests on a EC k=2, m=1
pool "VMPool0". We deploy some VMs (Windows, CentOS7) on the pool and then
use IOMeter to write data to these VMs. After a period of time, we observe
a strange thing that pool actual usage is much larger than stored da
Sean,
Thanks for your reply. I will test the perf on ARM.
On 7/7/2020 上午7:41, Sean Johnson wrote:
It should be fine. I use arm64 systems as clients, and would expect them to be
fine for servers. The biggest problem would be performance.
~ Sean
On Jul 6, 2020, 5:04 AM -0500, norman , wrote:
H
Hello,
I used:
ceph auth ls
to list all services keys and authorize configs to find that info and added it
to the keyring file that was missing it
it worked for a few days and now this morning same error warning but the
caps mgr = "profile crash"
caps mon = "profile crash"
are still in
It should be fine. I use arm64 systems as clients, and would expect them to be
fine for servers. The biggest problem would be performance.
~ Sean
On Jul 6, 2020, 5:04 AM -0500, norman , wrote:
> Hi all,
>
> I'm using Ceph on X86 and ARM, is it safe make x86 and arm64 in the same
> cluster?
>
On 2020-07-06 14:52, Igor Fedotov wrote:
Hi Stefan,
looks like bluefs allocator is unable to provide additional space for
bluefs log. The root cause might be lack of free space and/or high space
fragmentation.
Prior log lines and disk configuration (e.g. ceph-bluestore-tool
bluefs-bdev-size
A quick update.
I have done a fresh install of the CloudStack host server running Ubuntu 18.04
with the latest updates. I've installed ceph 12.x and connected it to
Cloudstack which uses kvm/libvirt/ceph/rbd. The rest of the ceph services
(mon,mgr,osd,etc) are all running 15.2.3. Works like a
Hi everyone,
Get ready for July 23rd at 17:00 UTC another Ceph Tech Talk but a
different scale: running small Ceph clusters in multiple data centers.
Thanks to Yuval Freund for giving time to provide us content this month.
You can find the calendar invite and archive here:
https://ceph.io/ce
On 7/07/2020 2:41 am, Etienne Mula wrote:
Update on this one , we have now changed the active ceph_mgr to another
instance and now getting :
0 mgr[zabbix] Exception when sending: 'zabbix_sender'
strange thing since using zabbix_sender is still working.
What user to it run as when ceph_mgr r
Just to confirm, you did configure a trapper host in Zabbix, and then you
pointed the mgr Zabbix sender to the Zabbix server (or proxy) with the same
hostname?
> $ ceph zabbix config-show | jq
> {
> "zabbix_port": 10051,
> "zabbix_host": "$server_or_proxy_ip_or_fqdn",
> "identifier": "ceph
Another update. The cluster seems to be stable now with a custom build
ceph-osd binary that reverts commit 30061:
https://github.com/ceph/ceph/pull/30061
The issue has been updated with the information:
https://tracker.ceph.com/issues/46366?next_issue_id=46365&prev_issue_id=46367#note-5
kind
etiennemula＠gmail.com wrote:
> Hello All,
>
> We are trying to make work the Zabbix module of our ceph cluster but im
> encountering an
> issue that got me stuck.
>
> Configuration of the module looks ok and we manage to send data using
> zabbix_sender to the
> host that is configured on Zabb
Hi,
On 03/07/2020 19:44, Oliver Freyermuth wrote:
Am 03.07.20 um 20:29 schrieb Dimitri Savineau:
You can try to use ceph-ansible which supports baremetal and
containerized deployment.
https://github.com/ceph/ceph-ansible
Thanks for the pointer! I know about ceph-ansible. The problem is
that
Hi List,
On of our clusters there are a couple of OSDs that keep crashing:
/build/ceph-13.2.8/src/os/bluestore/BlueFS.cc: 1576: FAILED assert(r == 0)
ceph version 13.2.8 (5579a94fafbc1f9cc913a0f5d362953a5d9c3ae0) mimic (stable)
1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>> caps mgr = "profile crash"
>> caps mon = "profile crash"
>>I added that back in and now its OK.
>> /var/lib/ceph/./crash.node1/keyring
do you add thsoe "caps" line into the "crash.node1/keyring" file or any other
files?
___
ceph-users mailing list -
should the key be the same on all 3 servers?
The values in the fiel are all different:
/var/lib/ceph/474629b4-bd04-11ea-a0bb-sfsfsfdsfs/crash.ceph0-ote/keyring
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-
Hello All,
We are trying to make work the Zabbix module of our ceph cluster but im
encountering an issue that got me stuck.
Configuration of the module looks ok and we manage to send data using
zabbix_sender to the host that is configured on Zabbix. We can also see this
data/metric in the gr
Hello All,
We are trying to make work the Zabbix module of our ceph cluster but im
encountering an issue that got me stuck.
Configuration of the module looks ok and we manage to send data using
zabbix_sender to the host that is configured on Zabbix. We can also see this
data/metric in the gr
Hi Stefan,
looks like bluefs allocator is unable to provide additional space for
bluefs log. The root cause might be lack of free space and/or high space
fragmentation.
Prior log lines and disk configuration (e.g. ceph-bluestore-tool
bluefs-bdev-sizes) might be helpful for further analysis.
An update about the progression of this issue:
After a few hours of normal operation the problem is now back in full swing.
About ten, this time different osd's, have started crashing on segfaults
again.
kind regards,
Wout
42on
On 2020-07-06 09:23, Wout van Heeswijk wrote:
Hi Dan,
Yes the
Hi all,
I'm using Ceph on X86 and ARM, is it safe make x86 and arm64 in the same
cluster?
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
+1 from me
I also hope for a bare metal solution for the upcoming versions. At the moment
it is a show stopper for an upgrade to Octopus.
Thanks everybody involved for the great storage solution!
Cheers,
Lars
Am Fri, 3 Jul 2020 20:44:02 +0200
schrieb Oliver Freyermuth :
> Of course, no solutio
Hi all,
We're planning to upgrade an existing testing 14.2.6 CEPH cluster to latest
15.2.4.
Existing cluster was deployed using ceph-ansible and we're still searching
steps to do the upgrade.
Shall we do the upgrade with steps like following ?
- Upgrade rpm on all nodes (mon/mgr first
Hi Markus,
Did you make any progress with this?
(Selfishly pinging to better understand whether the 14.2.9 to 14.2.10
upgrade is safe or not)
Cheers, Dan
On Wed, Jul 1, 2020 at 9:30 AM Dan van der Ster wrote:
>
> Hi Markus,
>
> Yes, I think you should open a bug tracker with more from a crashi
Hi Dan,
Yes the require-osd-release is set to octopus. I did see the threads
about the memory consumption with omap conversion. Since we did not
experience any problems at all with the restarting of the osd's in terms
of load or time I don't expect this is the issue.
We gained control over the
27 matches
Mail list logo
