Recent content by alexskysilk

https://docs.netapp.com/us-en/netapp-solutions-virtualization/proxmox/proxmox-deploy-guidelines.html --edit with video: https://docs.netapp.com/us-en/netapp-solutions-virtualization/proxmox/proxmox-ontap-nfs.html#storage-administrator-tasks

This is a great breakdown of your progress, and hitting that 90% threshold on CPU and network is a solid milestone. However, regarding the storage deficit (the 50% delta on Ceph vs. Bare Metal), I want to save you some cycles on the "further research" phase. You are running into an...

hmm. yes, I see your point. I am guilty of thinking of PVE as an infrastructure. I forget that many (most?) of its users are homelabbers. consider me chastised :)

True generally, untrue in the OPs testing matrix. LVM-thin introduces its own problems. Since it is of almost no benefit in a modern deployment (LVM thick for SAN, zfs/btrfs for local) I dont know why OP even bothered testing it.

Yes. For Kubernetes nodes to interact with Ceph directly (via RBD or CephFS), they need to be on the Ceph public network. Without that direct line of sight, the Kubernetes workers won't be able to map the block devices or mount the filesystems natively. It depends entirely on your current...

a container in zombie state would do what you experience. use ps to find the process (it would be in a permanent 'D' state.) The good news is that the rest of your containers work normally and you can use pct commands to control them. the bad news is that if you cant remove the process using...

zfs list -t all df -h

1. any storage back end should serve that stated requirement. be aware that meeting a performance spec defined as "decent" may have different meaning for different people. 2. 15k iops is doable. In your environment, lvm type will yield the best performance. As you did not mention any other...

Congratulations on your new environment. Before you can really make rational decisions for storage deployment you really need to consider what you want/need out of the equipment in a holistic manner. 1. What are you deploying on the equipment? 2. What are you performance floor requirements...

for the purposes of this conversation, disk passthrough and jbod is the same thing. and yes, you can and should use it. As for "best way," it really depends on what you want your "nas" to actually do. I am never a fan or running storage that is dependent on a different "compute" device within...

thats a smb bridgehead :) although I would use a VM for the purpose instead. and yes, you can mount cephfs inside a vm.

the Ceph stack provided by PVE is designed for use in a PVE hypervisor environment; I totally get the desire to comingle cephfs and rbd but in this specific case your choice is comingle and use your own SMB bridgeheads, or deploy a standard ceph cluster instead of the PVE integrated one. Both...

I think we're actually on the same page- its the meaning we take from it that is different. "safety" in this context is the continued uninterrupted delivery of service. the SAFEST thing to do in production is LEAVE A WORKING ENVIRONMENT ALONE. This is impractical for many reasons in a PVE...

No. that would be the test repo. see the section IMMEDIATELY BELOW the link you posted. Fair, but if his concern is whether he is licensed to use the software for any purpose the answer is simple and definitive: yes. If he's wondering if he's "safe" operating without a support contract, thats...

Right in practice, completely wrong in principle. you have license to use any software in either repo. you dont have ACCESS to the enterprise repo without entitlement. You COULD set up a tracking repo to the enterprise rep just like Centos did with RHEL and be completely within your rights. I...