Search results

It really depends. If the cluster is large enough to spread over several racks with rack being the failure zone you could argue that you do not need redundant top of rack switches. The loss of a whole rack can then be easily mitigated. But yes, in small clusters network redundancy is a must.

VXLAN packets are transported via UDP. Switches and other network hops do not need any special configuration.

Nein, die dreifache Replikation bezieht sich auf den Pool und die Objekte darin. OSDs kann ein Ceph-Cluster tausende haben. Die Objektkopien werden gleichmäßig auf sie verteilt.

Sehr geringe Latenz ist bei Ceph nur schwer zu erreichen, gerade bei nur 3 Knoten. Warum nicht in allen 9 Knoten OSDs ausrollen? Snapshots sind problemlos möglich.

Welchen CPU-Typ haben die VMs? Den generischen kvm64 oder host oder einen dazwischen?

A 1G network interface has a max bandwidth of around 100-120MB/s. This is why even 60MB/s seem to be fast for writing at least for me.

Writing to Ceph means three network trips instead of just one for LVM. A 1G network is way too slow for anything related to shared network storage.

Ceph uses local disks.

Some placement groups are currently deep scrubbing. This is normal and helps with data consistency.

This would define the availability zone at the root of the CRUSH map tree and will surely not work.

The loglines you posted from the Proxmox host contain dhclient lines which is unusual. Can you show more details about the "crash"? My suspicion is that dhclient on the host messes up the network config and this makes the host unreachable but does not crash it.

OK, but then they need to run their own DHCP client and not the Proxmox host. You have not posted log lines from the actual crash. Please set up remote syslogging or take a screen capture from the crash message.

Why is there a DHCP client running on your Proxmox server?

Does Pool 6 still have size=3? It is really not recommended to run OSDs on just two nodes.

Why do you want to create a Ceph pool (or even use Ceph at all) in a single Proxmox server?

This will not work. A physical interface can only be in one bonding interface.

1. There is an option to create new MAC addresses when cloning a VM template. 2. Remove /etc/machine-id as a last step before creating the VM template. A new machine ID will be created at first boot.

Does the kernel log any IO errors in the same time for this device?

cloud-init configures an account and the network settings inside a newly cloned VM. What is the connection to CephFS or RBD that is not working for you?

Yes, because the assumed failure zone is the host. If just an OSD fails it should be replaced. In small clusters the time to replace a failed disk is more crucial than in larger clusters where the data is more easily replicated to the other OSDs in the nodes.