this post was submitted on 30 Aug 2023
6 points (100.0% liked)

Plex

2501 readers
1 users here now

Welcome to Plex, a community dedicated to Plex, the media server/client solution for enjoying your media!

founded 1 year ago
MODERATORS
 

I’m looking for some feedback on my Plex system architecture.

All my media is stored on a Synology DS 1621+, six 4 TB drives in RAID 6 with one acting as a hot spare. All four network ports are bonded into a 4G link to an Ubiquiti USW-48-POE.

Previously, I ran Plex in a Docker container on the NAS. This setup was stable; however, the NAS only has 4 GB of memory shared between Plex, several other Docker services, and regular DSM overhead. Plus, the processor is not very powerful (AMD Ryzen V1500B, ~5400 PassMark).

A few months ago I repurposed some old desktop PC parts to build a home lab Proxmox server (Core i7-6700K [~8900 PassMark], 32 GB memory, GTX 970, an old 2.5” SATA SSD for guest OS disks, 1G networking on the motherboard). I’m running Plex on an Ubuntu VM, with the GPU passed through directly to the guest OS. Plex is not containerized in Ubuntu. The VM has 8 CPU cores and 8 GiB memory (different units in Proxmox). My Plex media is accessed via a persistent NFS mount in Ubuntu (had been SMB before a DSM update broke something and the VM could no longer read the directory contents.)

The main purpose of the change from NAS to VM was to utilize the increased CPU/GPU horsepower and memory that I had lying around, but I worry that the added layers of complexity (hypervisor/VM, PCIe pass through, NFS mounts) will introduce more opportunities for performance issues. I have noticed more frequent hiccups/buffering/transcoding since the change but I’m not sure if it’s related to my setup or if those issues lie with client devices and/or the files themselves (e.g. weird file container type that the client can’t play natively).

Any critique or recommendations on system architecture? Should I get a dedicated NIC to pass through to my VM? Dedicated NVMe drive passed through as a guest OS disk? Ditch Proxmox altogether and go back to Synology Docker container?

you are viewing a single comment's thread
view the rest of the comments
[–] liara@lemm.ee 1 points 1 year ago* (last edited 1 year ago) (1 children)

A complete kubernetes cluster for a homelab probably would be overkill (unless you really wanted a kubernetes playground, which some folks do). However, yes, my recommendation these days would be k0s directly. I did use k3s up until recently but gave k0s a shot and realized it's a bit lighter on resources, more configurable (for instance you can choose to run cri-o instead of containerd, which isn't an option with k3s) and has some extra features like letting you put helm charts with their values directly in the k0s config.

k0s vs k3s just comes down to personal preference but for me it came down to:

  • I disabled a lot of features of k3s out of the box (disabled flannel for calico, used nginx ingress instead of traefik). K0s feels a little less opinionated -- it doesn't include quite as many batteries during initialization, but this doesn't bother me because I have my own preferences for how to handle certain aspects of my stack
  • both can use sqlite as the data backend (and both will by default in single node mode), which is the much less resource usage than using etcd as the data store
  • I find k0s uses a couple hundred MB less RAM for the control plane components (about 700mb vs 1g for k3s)
  • less constant cpu usage from the API server
  • both have good documentation for their specific features and of course kubernetes itself is extremely well documented, which is "language" used to define the services and pods

As for distro to run it on, I use MicroOS myself (immutable os, I have it set to automatically update and reboot once a week), but Debian is my second choice and my personal preference for server distros. The beauty of this setup is the container host really just needs the bare minimum to run the containers. There's less that can break because the containers are all managed by others upstream so the main concern of breakage areas basically becomes did server boot and did k0s start?

NFS is fine and actually natively supported as a kubernetes volume type: https://kubernetes.io/docs/concepts/storage/volumes/

Your option could be to mount it directly to the host first and then use a hostPath to mount it to the container, or just mount the NFS path directly to the pod. As for permissions you may need to do some mapping, but kubernetes also has security contexts that can let you alter the UID of the user running the pod. If you need user to be privileged and root, you can do that or if you need UID 5124 you can do that too.

If your goal right now is a Plex server and not much else to start then this makes things very easy:

  • spin up k0s
  • add a Plex pod/manifest
  • add a service type of NodePort and expose the Plex service on a static node port of 32400 (we are lucky that Plex falls into the NodePort service range by default)
  • the GPU passthrough I admit will take some work, but it should be doable

You can add nginx ingress, cert-manager, metal lb, etc later on down the line if you get curious and want to expand a bit (sonarr, radarr, adguard home, etc)

You could also just go full stupid with kubevirt, but it's not a project I've personally explored using. Iirc it basically allows for the provisioning of more persistent VMs with k8s rather than containers

[–] keen1320@lemmy.world 1 points 1 year ago

Again, pardon my ignorance when it comes to Kubernetes. Why would I use something like k0s instead of just regular old Docker? I suspect PCIe passthrough will have similar challenges on both k0s and Docker, whereas on Proxmox it's been relatively painless.

This might be better suited for a different community, in which case I'll make a post where appropriate. I'm not familiar with some of the Kubernetes terminology - batteries, pod/manifest (is this similar to stacks/docker compose?), NodePort?