Search results

Yes until you setup some form of raid on the HP controller it will not pass through the disk to the OS. Make 6 indvidual Raid 0 (1 per a drive) in the HP Raid setup and Promox will then see these.

The issue may be that the vSwitch feature from hetzner is probably already making use of some form of QinQ (they would hit the max VLAN's on their switches very quickly otherwise) so you probably will need to drop their support a ticket to see if it is something that is actually supported.

Yes that CPU supports virtualization, so it will work. Just don't expect high performance from it, but if all you need is a low end box to run a VM or two from then yes it will do fine.

Sounds like you just have the Crash module enabled : https://docs.ceph.com/docs/master/mgr/crash/ Run : ceph crash archive-all This should remove the entry showing in the health output

Then you should have no issues, when comes to CEPH it is more about having enough nodes to split the replication across than amount of OSD per a node. As you said your have them across 4 servers if your using standard replication of 3 you can lose a node and still have a spare node to rebuild...

Depends on the crash, if its kernel panicking because it cant clear the ARC cache to disk quick enough for the memory demand only a screen really is the best way to see this. You could try adjusting the ARC to say 25% of the available RAM and monitor, but having the screen output during the...

Your ARC Cache is set to use 32GB of your ram (50%), do you have anything that runs around the time that the server crashes that could suddenly cause the containers to require extra RAM? Have you been able to connect a monitor to the server when it crashes and see if there is any output?

1/ What is the network your using for CEPH? 1/10Gbps? 2/ What model are the HDD disks your using? 3/ From where are you running the benchmark command?

Yes it's lost after a reboot / nic reset, add the post-up to the interface itself as it needs to be applied to the physical NIC itself and not the bridge.

What will the use case be for the SSD Pool? You will get more performance out of the SSDs pool than the SAS spinners pool even with a slightly lower OSD count, amount of OSD per a server really does not have that great effect, what is important is each OSD server still has plenty of CPU & RAM...

You should ideally always upgrade all the MON's first as seen here : https://docs.ceph.com/docs/master/install/upgrading-ceph/

That is the wrong command as the output says that command don't exist. "systemctl restart ceph.target " Is correct

How did you try and restart the OSD's? What was the output of the command?

You replied just saying the OSD's are fine and you just needed to refresh the screen. If still an issue what does ceph -s & ceph health detail Show?

Great, but yes after the upgrade of the packages you need to restart the OSD's / Server for the upgrade to take effect.

What does "ceph health detail" show?

What version were you going from? -> to? From your CEPH output, it doesn't look like there were any issues, CEPH OSD's dont actually update till you restart the OSD process. Some recent versions the OSD didn't reconnect to the new MON's till they were running the new version.

I think you really have no huge difference apart from having the single pane of glass to see both CEPH/Computer under the one Proxmox viewpoint vs having to log into two separate interfaces. You are nowhere near any node limits with Proxmox, only benefit I can see is you can upgrade the compute...

It shows you have one OSD down which is causing some PG's to be down, this will mean your be having I/O errors. Your need to work out which OSD is down and get the OSD back online, this will then hopefully bring your PG's online for your cluster to start working. What settings did you use when...

Same but I have this in my network config and never have any issues with hangs "post-up ethtool -K enp0s31f6 sg off tso off gro off"