With ceph-ansible it was possible to deploy Ganesha as a standalone service, that is, without deploying the Ceph cluster as well.
This was useful, for example, in TripleO when it didn't manage the Ceph cluster deployment but would still deploy Ganesha (via ceph-ansible) for Manila to serve CephFS via NFS.
Currently cephadm *can* deploy Ganesha but *only* via the orchestrator, not as a standalone service.
Comment 1RHEL Program Management
2020-11-05 14:56:06 UTC
We have an architectural problem here: Cephadm is in control of the MON deployment. A requested feature for cephadm is to failover daemons to different hosts, in case a host fails. In this case the MON quorum changes and cephadm deploys a new /etc/ceph/ceph.conf to all hosts in the cluster in order to avoid connection timeouts to MONs.
By deploying ganesha independent of the cluster orchestration, it will be affected by connection timeouts. Thus I don't recommend this path.
In fact, upstring is going into the opposite direction by also managing the ceph.conf on kernel-client hosts.
Is there a way for us to avoid this architecture?
Comment 11Sebastian Wagner
2021-05-05 08:30:27 UTC
Hi Francesco, hi John and hi Tom,
Haha, I'm sensing some desire to keep the existing Manila architecture :-)
Regarding VIPs for MONs, I don't think they'd give any benefit: (1) MONs need to have unique and a single dedicated IP addresses, which would by itself mandate a VIP per MON. (2) when migrating MONs to a different host, we're creating a new MON with it's own name.
Regarding standalone ganesha, very well then. But it won't be pretty.