Separate service data from host #15
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
To facilitate our migration to a distributed system architecture, we need to decouple service data from the host the service is presently running on. This applies to Fighter and Druid.
Fighter
There are four places we keep service data on Fighter:
/home/admin/data/$STACK/$SERVICE
/mnt/iscsi/{barbarian|paladin}
/mnt/nas/{barbarian|paladin}
Druid
I think we moved all our service data for Druid to the data volume, but I don't recall its path.
Action Items
Catalog data to be moved.
We got a list of all host-side paths for data mounts in containers with
docker inspect $(docker ps -aq) | jq .[].Mounts | grep Source | sort -u | cut -d'"' -f4
A few of these are not real data paths (
/run/dbus
or/var/run/docker.sock
), and some are remote filesystems (/mnt/*
). The rest are local data stores that should be moved. Next comment will be the filtered list of paths to move.Note: this only includes volumes for services that are running right now. So next we'll look at the dark data we might need to back up.
The
/home/admin/data
directory is only 34.4 GiB. Trivial to back up once we've configured a new storage solution.Re: Discover solutions for data storage suitable for distributed workloads.
Unless we switch from ZFS to CephFS (and make the massive infra migration necessary to support that), we'll have to stick with old--school SMB and iSCSI for network storage. But we can also bring Longhorn into the equation, which means we'll have three tiers of storage:
smb
Network file storageiscsi
Network block storagelonghorn
Distributed block storageThis may require adding more physical storage to each node to provide a useful amount storage.