Freenas zvol drivers#
I believe in the long-run this is actually how kubernetes may behave inherently if/when they begin using the ListVolumes functionality of csi drivers (which is implemented here) I'm currently exploring the import idea.I've considered altering how this behaves, but it was an explicitly chosen design decision for various other reasons to the trade-offs need to be thought through for sure.due to the above, you would likely run into issues migrating to a backup server as presumably the server is running with a different IP.currently, all the connection details (minus secrets) actually get stored as zfs props, of note here is this includes the portals/iscsi targets/etc (those values as stored in the config are not actually used by the attach process).Idk, maybe I'm way overthinking this and should leave data backup/migration to tools built specifically for that (like yes, all very good stuff! There are a couple of things to note here:
Freenas zvol install#
It's a lot faster to recover a multi-TB PV by pointing the cluster to a redundant copy of the PV (backup NAS) than it is to import/download multiple TBs over the wire into a newly-created PV.Īlternatively, if it's not TrueNAS that goes down but rather my k8s cluster, I could simply build a new cluster, install the CSI, scan TrueNAS for datasets/zvols and automatically have PVs created from them without needing to manually map each one. I'll likely end up going this way, however since the tooling already exists in TrueNAS and it works so well, it might be worth exploring first.
I spoke to a few other people about this kind of setup and they suggested I ignore using ZFS send/receive backups on the TrueNAS side and just stick 100% to using velero or some other backup software. This allows restore functionality to work in a cluster migration scenario, where the original backup objects do not exist in the new cluster. If there is a properly formatted backup file in the storage bucket, but no corresponding backup resource in the Kubernetes API, Velero synchronizes the information from object storage to Kubernetes. It continuously checks to see that the correct backup resources are always present. Velero treats object storage as the source of truth. It's an entirely different beast, but the way this description for Velero works makes me wonder if something like this could be built here as well: In the event that my primary storage server goes down it would be awesome if I could point the CSI to my backup NAS, scan configured location where my replicated datasets live, create PVs from them, and then map (manually or with a script) those PVs to PVCs in my cluster. This TrueNAS unit takes hourly and daily snapshots and replicates them to a secondary (all HDD) TrueNAS server.
To expand on this, would it be possible for the CSI to scan datasets in the configured location, identify datasets that don't have a corresponding PV in the cluster, and then create PVs from them based on the default (or a specified) StorageClass?įor example on the TrueNAS Core side of things I have an all-flash unit that's mapped to the CSI to provide storage for my cluster.
0 kommentar(er)
